| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>, "david(at)lang(dot)hm" <david(at)lang(dot)hm>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Slow count(*) again... |
| Date: | 2010-10-13 06:45:16 |
| Message-ID: | AANLkTimQcMKPVDuHgQC11COJ9_ad6zY1dwXtqMj8LxKq@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On Tue, Oct 12, 2010 at 1:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Anyway, if anyone is hot to make COUNT(*) faster, that's where to look.
> I don't think any of the previous discussion in this thread is on-point
> at all, except for the parts where people suggested avoiding it.
I kind of hope that index-only scans help with this, too. If you have
a wide table and a narrow (but not partial) index, and if the
visibility map bits are mostly set, it ought to be cheaper to read the
index than the table - certainly in the case where any disk I/O is
involved, and maybe even if it isn't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Whelchel | 2010-10-13 06:47:19 | Re: Slow count(*) again... |
| Previous Message | Heikki Linnakangas | 2010-10-13 06:43:36 | Re: Issues with Quorum Commit |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Whelchel | 2010-10-13 06:47:19 | Re: Slow count(*) again... |
| Previous Message | Robert Haas | 2010-10-13 06:40:40 | Re: How does PG know if data is in memory? |