On Tue, Feb 24, 2009 at 10:39 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On my system this takes about 45 ms to execute with default settings >> and about 90 ms to execute with index scan disabled. > > [ shrug... ] That's well within my threshold of pain for this. > In any case, it might be possible to buy some/all of that back with > minor optimization effort on the bitmap-scan code paths; nobody's > ever really bothered to profile that AFAIK. There is no real > difference in the useful work (page and tuple fetches) getting done > in the two cases, so there's no reason in principle for bitmap scan > to be much slower than indexscan here. The LIMIT case is the only > one I'm aware of where there's a fundamental reason that bitmap scan > should be slower.
Uh, a semi or anti join stops as soon as one matching row is found, doesn't it? ISTM that a semi or anti join is in essence an iterated limit 1 clause. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
