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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
