Re: [RFC] speed up count(*)
От | Tom Lane |
---|---|
Тема | Re: [RFC] speed up count(*) |
Дата | |
Msg-id | 2258417.1634752670@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [RFC] speed up count(*) (John Naylor <john.naylor@enterprisedb.com>) |
Ответы |
Re: [RFC] speed up count(*)
Re: [RFC] speed up count(*) |
Список | pgsql-hackers |
John Naylor <john.naylor@enterprisedb.com> writes: > Perennially our users have complaints about slow count(*) when coming from > some other systems. Index-only scans help, but I think we can do better. I > recently wondered if a BRIN index could be used to answer min/max aggregate > queries over the whole table, and it turns out it doesn't. However, then it > occurred to me that if we had an opclass that keeps track of the count in > each page range, that would be a way to do a fast count(*) by creating the > right index. That would require planner support and other work, but it > seems doable. Any opinions on whether this is worth the effort? The core reason why this is hard is that we insist on giving the right answer. In particular, count(*) is supposed to count the rows that satisfy the asker's snapshot. So I don't see a good way to answer it from an index only, given that we don't track visibility accurately in indexes. regards, tom lane
В списке pgsql-hackers по дате отправления: