Re: GiST index performance - Mailing list pgsql-performance

From Matthew Wakeling
Subject Re: GiST index performance
Date
Msg-id alpine.DEB.2.00.0904211134580.22330@aragorn.flymine.org
Whole thread Raw
In response to GiST index performance  (Matthew Wakeling <matthew@flymine.org>)
Responses Re: GiST index performance
List pgsql-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

pgsql-performance by date:

Previous
From: Richard Huxton
Date:
Subject: Re: performance for high-volume log insertion
Next
From: Kenneth Marshall
Date:
Subject: Re: performance for high-volume log insertion