Re: GIN, partial matches, lossy bitmaps

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