On Mon, 2009-03-02 at 21:14 +0200, Heikki Linnakangas wrote:
> If I'm reading the code correctly, item pointers of all matching heap
> tuples are first collected into a TIDBitmap, and then amgetnext returns
> tuples from that one by one. If the bitmap becomes lossy, an error is
> thrown. gingetbitmap is a dummy implementation: it creates a new
> TIDBitmap and inserts all the tuples from the other TIDBitmap into it
> one by one, and then returns the new TIDBitmap.
Do you think that might be the cause of the extra startup overhead that
Robert Haas observed for bitmap scans?
> If we remove the support for regular, non-bitmap, index scans with GIN,
> that could be cleaned up as well. Even if we don't do that, gingetbitmap
> should not error when the bitmap becomes lossy, but just return the
> lossy bitmap.
That sounds reasonable to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
