| From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | [RFC] speed up count(*) |
| Date: | 2021-10-20 17:51:41 |
| Message-ID: | CAFBsxsGn-LePDQksLdceecyipHdhaEh0G=oXFgdQNwyV7LGUfA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
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?
--
John Naylor
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-10-20 17:57:50 | Re: [RFC] speed up count(*) |
| Previous Message | Mark Dilger | 2021-10-20 17:32:51 | Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) |