Re: GiST index performance

От: Tom Lane
Тема: Re: GiST index performance
Дата: ,
Msg-id: 6704.1240241220@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: 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, )

Matthew Wakeling <> writes:
> I have found a bug in the contrib package seg, which has been copied into
> the bioseg data type as well. It causes the index to be created with
> horribly bad unselective trees, so that when a search is performed many of
> the branches of the tree need to be followed. This explanation does not
> extend to btree_gist, so I will have to further investigate that. Apply
> the following patch to contrib/seg/seg.c:

> *** seg.c    2006-09-10 18:36:51.000000000 +0100
> --- seg.c_new    2009-04-20 15:02:52.000000000 +0100
> ***************
> *** 426,432 ****
>            else
>            {
>                datum_r = union_dr;
> !             size_r = size_alpha;
>                *right++ = i;
>                v->spl_nright++;
>            }
> --- 426,432 ----
>            else
>            {
>                datum_r = union_dr;
> !             size_r = size_beta;
>                *right++ = i;
>                v->spl_nright++;
>            }

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)?

            regards, tom lane


В списке pgsql-performance по дате сообщения:

От: "Mark Lewis"
Дата:
Сообщение: Re: SQL With Dates
От: david@lang.hm
Дата:
Сообщение: performance for high-volume log insertion