Re: bitmap-index-scan faster than seq-scan on full-table-scan (gin index)
От | Tom Lane |
---|---|
Тема | Re: bitmap-index-scan faster than seq-scan on full-table-scan (gin index) |
Дата | |
Msg-id | 18522.1275336564@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | bitmap-index-scan faster than seq-scan on full-table-scan (gin index) (Jesper Krogh <jesper@krogh.cc>) |
Ответы |
Re: bitmap-index-scan faster than seq-scan on full-table-scan
(gin index)
|
Список | pgsql-hackers |
Jesper Krogh <jesper@krogh.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
В списке pgsql-hackers по дате отправления: