On Mon, Mar 2, 2009 at 3:02 PM, Jeff Davis <pg...@j-davis.com> wrote: > 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?
I don't think this is the same thing. My point was that an index scan wins big time over a bitmap index scan when the index scan doesn't need to be run to completion - that is, when the query is a semi-join or an anti-join, or when using LIMIT without ORDER BY. This is true with or without Teodor's patch, and is the reason why I'm not sure that removing index scan support is such a great idea. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers