Re: the big picture for index-only scans
От | Bruce Momjian |
---|---|
Тема | Re: the big picture for index-only scans |
Дата | |
Msg-id | 201105110300.p4B30pk04429@momjian.us обсуждение исходный текст |
Ответ на | Re: the big picture for index-only scans (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > 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. OK, would the clustering analyze stats (pg_stats.correlation) tell us that? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: