From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Abe Ingersoll <abe(at)abe(dot)us> |
Subject: | Re: Fixing GIN for empty/null/full-scan cases |
Date: | 2011-01-15 07:37:31 |
Message-ID: | 28DFB44A-79A0-4C95-8488-18F5DE427970@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jan 14, 2011, at 5:54 PM, Tom Lane wrote:
> "David E. Wheeler" <david(at)kineticode(dot)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 be faster 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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-01-15 08:02:30 | Re: auto-sizing wal_buffers |
Previous Message | Greg Smith | 2011-01-15 07:01:36 | Re: auto-sizing wal_buffers |