Re: the big picture for index-only scans
От | Tom Lane |
---|---|
Тема | Re: the big picture for index-only scans |
Дата | |
Msg-id | 17411.1305080982@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: the big picture for index-only scans (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: the big picture for index-only scans
Re: the big picture for index-only scans |
Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> writes: > Greg Stark wrote: >> Putting aside the politics questions, count(*) is an interesting case >> -- it exposes some of the unanswered questions about index-only scans. >> >> The reason "select count(*)" might win would be because we could pick >> any index and do an index scan, relying on the visibility map to >> optimize away the heap reads. This is only going to be a win if a >> large fraction of the heap reads get optimized away. >> >> It's going to be pretty tricky to determine in the optimizer a) which >> index will be cheapest and b) what fraction of index tuples will point > I assume the smallest non-partial index would be the cheapest index. That will be true only if you intentionally ignore the points Greg raised. If the table isn't entirely ALL_VISIBLE, then the choice of index will determine the ordering of the actual table probes that occur. There could be more or fewer page reads, in a more or less optimal order, depending on the index used. regards, tom lane
В списке pgsql-hackers по дате отправления: