]> granicus.if.org Git - postgresql/commit
Further cleanup of gistsplit.c.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 10 Feb 2013 21:21:32 +0000 (16:21 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 10 Feb 2013 21:21:32 +0000 (16:21 -0500)
commita2cf57f5e0c43689cd2e6ccf8f1378b02db6e50f
tree15f33526f8c903acf50e241e0f9e31bb5c4c45ef
parent4ce3fa1f91d99257cb7fb617609f93ed6bb326f7
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.
src/backend/access/gist/gistsplit.c