aboutsummaryrefslogtreecommitdiff
path: root/src/tutorial/complex.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2013-02-10 16:21:32 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2013-02-10 16:21:32 -0500
commita2cf57f5e0c43689cd2e6ccf8f1378b02db6e50f (patch)
tree15f33526f8c903acf50e241e0f9e31bb5c4c45ef /src/tutorial/complex.c
parent4ce3fa1f91d99257cb7fb617609f93ed6bb326f7 (diff)
downloadpostgresql-a2cf57f5e0c43689cd2e6ccf8f1378b02db6e50f.tar.gz
postgresql-a2cf57f5e0c43689cd2e6ccf8f1378b02db6e50f.zip
Further cleanup of gistsplit.c.
After further reflection I was unconvinced that the existing coding is guaranteed to return valid union datums in every code path for multi-column indexes. Fix that by forcing a gistunionsubkey() call at the end of the recursion. Having done that, we can remove some clearly-redundant calls elsewhere. This should be a little faster for multi-column indexes (since the previous coding would uselessly do such a call for each column while unwinding the recursion), as well as much harder to break. Also, simplify the handling of cases where one side or the other of a primary split contains only don't-care tuples. The previous coding used a very ugly hack in removeDontCares() that essentially forced one random tuple to be treated as non-don't-care, providing a random initial choice of seed datum for the secondary split. It seems unlikely that that method will give better-than-random splits. Instead, treat such a split as degenerate and just let the next column determine the split, the same way that we handle fully degenerate cases where the two sides produce identical union datums.
Diffstat (limited to 'src/tutorial/complex.c')
0 files changed, 0 insertions, 0 deletions