Re: GiST subsplit question

On Wed, May 30, 2012 at 11:21 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:

> I looked for the follow-up commit to support subsplit in the contrib
> modules, figuring that would answer some questions, but I couldn't find
> it.
>
> The part that's confusing me is that the commit message says: "pickSplit
> should set spl_(l|r)datum_exists to 'false'", but I don't see any
> picksplit method that actually does that in contrib, nor in the sample
> in the docs.
>

The only picksplit implementation I know to support secondary split
is fallbackSplit in gistproc.c :). I didn't understand how secondary split
works until I get deep into GiST code.

The code in that area is a bit difficult to follow, so it's not obvious
> to me exactly what is supposed to happen.
>

When GiST split index tupes by first column, it find if some tuples can be
equally placed to any of groups. If so it calls picksplit for second column
with only that tuples. But we already now that some keys of second column
should be placed to particular groups, because some tuples are already
unambiguously
placed to the groups. GiST calculates union of that keys of second column
for each group and pass it as ldatum and rdatum to pisckplit function of
second column. In order to indicate such secondary split GiST set
ldatum_exists and rdatum_exists flags. If picksplit function support
secondary split, it should join given keys to existing ldatum and rdatum
and set off ldatum_exists and rdatum_exists flags. If picksplit function
don't support secondary split than in leave ldatum_exists and rdatum_exists
as is, and GiST decide how to join picksplit result with existing groups
itself by using penalty function. Also it is possible than only one of
ldatum_exists
and rdatum_exists flags is set. It indicated that there aren't not null
keys of second column which unambiguously join group which flag isn't set.
In this case pisksplit function which support secondary split can form one
of ldatum or rdatum (which flag isn't set) without limitations.

> So, do we demote that message to a DEBUG1? Or do we make it more clear
> what the authors of a specific picksplit are supposed to do to avoid
> that problem? Or am I misunderstanding something?
>

+1 for demote message to DEBUG1. I think it shouldn't be so noisy, it just
indicates something could be improved.
Also I think we defenitely need to document secondary split. Now it's no
chances to understand without reverse engeneering it from code.

------
With best regards,
Alexander Korotkov.