diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2013-02-10 16:21:26 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2013-02-10 16:21:26 -0500 |
commit | c352ea2d74c4e317bf2a1471ec1f750f9f072276 (patch) | |
tree | 0a0160901fedd75f0a49ad0b57778b312b863a7c /src/backend/access/gist/gistvacuum.c | |
parent | db3d7e9f0d7d2a7edf57d154f62dff0a18f1b1f9 (diff) | |
download | postgresql-c352ea2d74c4e317bf2a1471ec1f750f9f072276.tar.gz |
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/backend/access/gist/gistvacuum.c')
0 files changed, 0 insertions, 0 deletions