GIN, partial matches, lossy bitmaps

While reading the GIN code, I just rediscovered that the GIN partial 
match support suffers from the same problem that I criticized the "fast 
insert" patch about, and searching the archives I found that I already 
complained about that back in April:

http://archives.postgresql.org/pgsql-patches/2008-04/msg00157.php

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.

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.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com