Re: bitmap-index-scan faster than seq-scan on full-table-scan (gin index)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jesper Krogh <jesper(at)krogh(dot)cc>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: bitmap-index-scan faster than seq-scan on full-table-scan (gin index)
Date: 2010-05-31 20:09:24
Message-ID: 18522.1275336564@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jesper Krogh <jesper(at)krogh(dot)cc> writes:
> Conceptually searching for the "full dataset" would always be fastest
> solved by a seq-scan. The query planner enforces this so much, so not
> even "enable_seqscan=off" can convince it to to something else.
> ...
> Would it be possible to implement the "Filtering" using the gin-index and
> a subsequent visibillity-check as on the index-scan?

You're failing to make any sense whatsoever. If you're reading the full
dataset, there is no filter condition. If there is a potentially
indexable filter condition, the planner will certainly consider that.

Personally I think the issue here has got more to do with the
non-immutability of the single-argument form of to_tsquery, which means
it gets re-evaluated at every row during a seqscan. Do your results
change if you work with to_tsquery('english', ...) (or whatever your
default TS config is)?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-05-31 20:12:12 Re: why do we have rd_istemp?
Previous Message Bruce Momjian 2010-05-31 20:03:57 Re: why do we have rd_istemp?