Re: GiST index performance

От: Matthew Wakeling
Тема: Re: GiST index performance
Дата: ,
Msg-id: alpine.DEB.2.00.0904211134580.22330@aragorn.flymine.org
(см: обсуждение, исходный текст)
Ответ на: GiST index performance  (Matthew Wakeling)
Ответы: Re: GiST index performance  (Matthew Wakeling)
Список: pgsql-performance

Скрыть дерево обсуждения

GiST index performance  (Matthew Wakeling, )
 Re: GiST index performance  ("Kevin Grittner", )
  Re: GiST index performance  (Matthew Wakeling, )
  Re: GiST index performance  (Tom Lane, )
   Re: GiST index performance  (Matthew Wakeling, )
    Re: GiST index performance  (Tom Lane, )
     Re: GiST index performance  (Matthew Wakeling, )
   Re: GiST index performance  (Matthew Wakeling, )
    Re: GiST index performance  (Matthew Wakeling, )
     Re: GiST index performance  (Tom Lane, )
 Re: GiST index performance  (Matthew Wakeling, )
 Re: GiST index performance  (dforum, )
  Re: GiST index performance  (Tom Lane, )
  Re: GiST index performance  (Craig Ringer, )
 Re: GiST index performance  (Matthew Wakeling, )
  Re: GiST index performance  (Matthew Wakeling, )
   Re: GiST index performance  (Matthew Wakeling, )
    Re: GiST index performance  (Tom Lane, )
     Re: GiST index performance  (Oleg Bartunov, )
 Re: GiST index performance  (Matthew Wakeling, )
  Re: GiST index performance  (Bruce Momjian, )
   Re: GiST index performance  (Robert Haas, )
    Re: GiST index performance  (Bruce Momjian, )

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 по дате сообщения:

От: Stephen Frost
Дата:
Сообщение: Re: performance for high-volume log insertion
От: david@lang.hm
Дата:
Сообщение: Re: performance for high-volume log insertion