From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [RFC] speed up count(*) |
Date: | 2021-10-20 17:57:50 |
Message-ID: | 2258417.1634752670@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
John Naylor <john(dot)naylor(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-10-20 18:22:10 | Re: [RFC] speed up count(*) |
Previous Message | John Naylor | 2021-10-20 17:51:41 | [RFC] speed up count(*) |