Re: Index Scans become Seq Scans after VACUUM ANALYSE
От | Stephan Szabo |
---|---|
Тема | Re: Index Scans become Seq Scans after VACUUM ANALYSE |
Дата | |
Msg-id | 20020416174111.O53171-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: Index Scans become Seq Scans after VACUUM ANALYSE (Michael Loftis <mloftis@wgops.com>) |
Список | pgsql-hackers |
On Tue, 16 Apr 2002, Michael Loftis wrote: > I know I know, replying to myself is bad and probably means I'm going > insane but thought of one other thing... > > Realistically the system should choos *ANY* index over a sequential > table scan. Above a fairly low number of records any indexed query > should be much faster than a seqscan. Am I right, or did I miss > something? (wouldn't be the first time I missed something)... Right Because the validity information is stored with the row and not the index you have to read rows for any potential hit in the index. Depending on the clustering of the table, the width of the rows and the percentage of the table being hit by the scan (or estimated to be hit) you may read most or all of the table as well as the index and be paying a penalty for doing it randomly as opposed to be sequentially. IIRC, there are some settings in the configuration that let you play around with the relative costs the estimator uses (the random page cost and cpu costs for dealing with index entries and such).
В списке pgsql-hackers по дате отправления: