Re: GiST index performance

On Mon, 20 Apr 2009, Teodor Sigaev wrote:
>> Looks like contrib/cube has the same error. I don't see a similar code
>> pattern elsewhere though. Oleg, Teodor, do you concur that this is a
>> correct patch? Is it safe to back-patch (I think it should be)?
> Yeah, good catch, and it doesn't touch any already-on-disk data. Although
> release notes should mention advice about REINDEX seg and cube opclasses.

Unfortunately, it seems there is another bug in the picksplit function.
My patch fixes a bug that reveals this new bug. The whole picksplit
algorithm is fundamentally broken, and needs to be rewritten completely,
which is what I am doing.

If you apply my patch, then index sizes will go up by a factor of ten or
so, because the picksplit function tends to split the set of 367 ranges
into one set of 366 and another set of 1, leading to a horribly unbalanced
tree. Before the patch, the different branches of the tree were
unselective, so new entries would just get stuffed in anywhere, leading to
a much more "balanced" tree.

I shall have a proper fix to this problem later today.

Matthew

--
It's one of those irregular verbs - "I have an independent mind," "You are
an eccentric," "He is round the twist."
-- Bernard Woolly, Yes Prime Minister