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

From Tom Lane
Subject Re: GIN, partial matches, lossy bitmaps
Date
Msg-id 17706.1236296124@sss.pgh.pa.us
Whole thread Raw
In response to Re: GIN, partial matches, lossy bitmaps  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: GIN, partial matches, lossy bitmaps  (Robert Haas <robertmhaas@gmail.com>)
Re: GIN, partial matches, lossy bitmaps  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
> Changes since 28.2
> (http://archives.postgresql.org/message-id/499B0FFA.8040608@sigaev.ru)

> - fixes/changes pointed by Robert
> (http://archives.postgresql.org/pgsql-hackers/2009-02/msg00987.php)
> - gingetbitmap will never throw error about lossiness of bitmap, it will return
> lossy bitmap even it was a prefix search.
> - remove tbm_check_tuple/tbm_has_lossy/tbm_max_non_lossy methods because they
> become unused
> - add new method tbm_add_page(TIDBitmap*, BlockNumber) to add the whole page to
> the TIDBitmap.

I cleaned up and applied the planner part of this, since that seems
reasonably useful in its own right for experimental index AMs,
regardless of where we settle out for GIN.  (The "cleanup" mostly
consisted of fixing it to not make extra calls to find_usable_indexes
--- that's an expensive function, and there's no very good reason to
run it another time rather than separating out the indexes afterwards.)

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.

            regards, tom lane


Attachment

pgsql-hackers by date:

Previous
From: Joshua Tolley
Date:
Subject: Re: Make SIGHUP less painful if pg_hba.conf is not readable
Next
From: Josh Berkus
Date:
Subject: Can we drop ABSTIME?