Re: Fixing GIN for empty/null/full-scan cases
От | David E. Wheeler |
---|---|
Тема | Re: Fixing GIN for empty/null/full-scan cases |
Дата | |
Msg-id | 0ED8D4B6-6FC8-4C7A-ADA8-FF4992C253DD@kineticode.com обсуждение исходный текст |
Ответ на | Re: Fixing GIN for empty/null/full-scan cases ("David E. Wheeler" <david@kineticode.com>) |
Список | pgsql-hackers |
On Jan 14, 2011, at 11:37 PM, David E. Wheeler wrote: >> 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. FWIW, it looks like we're able to fix the GiST performance by using gist__intbig_ops. Relevant thread: http://archives.postgresql.org/pgsql-performance/2009-03/msg00254.php Perhaps time to revisit using gist__int_ops as the default? > 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 по дате отправления: