Re: Fixing GIN for empty/null/full-scan cases

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: Fixing GIN for empty/null/full-scan cases
Дата
Msg-id 28DFB44A-79A0-4C95-8488-18F5DE427970@kineticode.com
обсуждение исходный текст
Ответ на Re: Fixing GIN for empty/null/full-scan cases  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fixing GIN for empty/null/full-scan cases  ("David E. Wheeler" <david@kineticode.com>)
Список pgsql-hackers
On Jan 14, 2011, at 5:54 PM, Tom Lane wrote:

> "David E. Wheeler" <david@kineticode.com> writes:
>> So some questions:
>
>> * Is something seriously wrong with GiST index creation on integer[] columns?
>
>> * Why does GIN performance appear to be no better than table scans on integer[] columns?
>
>> * Why does it take 3-4x longer to create the GIN than the GiST index on tsvector? I thought that GIN was supposed to
befaster to update 
>
> Hard to comment on any of this without a concrete example (including
> data) to look at.  Given the bugs we've recently found in the picksplit
> algorithms for other contrib modules, I wouldn't be too surprised if the
> sucky GiST performance traced to a similar bug in intarray.  But I'm not
> excited about devising my own test case.

I could give you access to the box in question if you'd like to poke at it. Send me a public key.

> One other point here is that GIN index build time is quite sensitive to
> maintenance_work_mem --- what did you have that set to?

64MB

Best,

David



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: auto-sizing wal_buffers
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: auto-sizing wal_buffers