Re: GIN, partial matches, lossy bitmaps - Mailing list pgsql-hackers

From Robert Haas
Subject Re: GIN, partial matches, lossy bitmaps
Date
Msg-id 603c8f070903051850u5c5460dai1b90a6cae175e855@mail.gmail.com
Whole thread Raw
In response to Re: GIN, partial matches, lossy bitmaps  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: GIN, partial matches, lossy bitmaps
List pgsql-hackers
On Thu, Mar 5, 2009 at 6:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Attached is the remainder of the patch with relatively minor fixes.
> The main change I made is to get rid of the changes in gincostestimate;
> I agree with Robert that it's probably inappropriate to consider the
> current pending-list size during planning.  I haven't really reviewed
> any of the rest of it; this is just to have a clean patch against HEAD.

The changes to config.sgml are not good English and contain
typographical errors.  It could also be a bit more informatiave, maybe
something like:

This parameter also specifies the number of insert or updated tuples
needed to trigger <command>VACUUM</> on a <acronym>GIN</acronym>
index.   <acronym>GIN</acronym> indexes require <command>VACUUM</>
after insert or update operations because newly inserted tuples are
initially stored in an unsorted pending list.

I still think removing index scans entirely is short-sighted - but I
may be outvoted (then again, no one other than Tom has really
expressed an opinion one way or the other, and I initially agreed with
him until I thought about the performance aspects some more).

...Robert


pgsql-hackers by date:

Previous
From: Sophie Yang
Date:
Subject: Re: Use array in a dynamic statement
Next
From: Robert Haas
Date:
Subject: Re: Use array in a dynamic statement