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
|
Список | 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 по дате отправления: