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

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-17 06:42:32
Message-ID: 0ED8D4B6-6FC8-4C7A-ADA8-FF4992C253DD@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-01-17 06:44:58 Re: replication and pg_hba.conf
Previous Message Magnus Hagander 2011-01-17 06:37:15 Re: psql: Add \dL to show languages