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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fixing GIN for empty/null/full-scan cases
Дата
Msg-id 16000.1295056491@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fixing GIN for empty/null/full-scan cases  (David E. Wheeler <david@kineticode.com>)
Ответы Re: Fixing GIN for empty/null/full-scan cases  ("David E. Wheeler" <david@kineticode.com>)
Список pgsql-hackers
"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.

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


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

Предыдущее
От: Jaime Casanova
Дата:
Сообщение: Re: Named restore points
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Add support for logging the current role