From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: So, is COUNT(*) fast now? |
Date: | 2011-10-24 17:51:59 |
Message-ID: | 4364.1319478719@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I had wondered whether it'd be worth optimizing that along the
>> lines of slot_getallattrs(). But most indexes probably have only
>> one column, or anyway not enough to make for a useful savings.
>> From a heavily-used production database:
> cir=> select indnatts, count(*) from pg_index group by indnatts
> order by indnatts;
> indnatts | count
> ----------+-------
> 1 | 200
> 2 | 684
> 3 | 155
> 4 | 76
> 5 | 43
> 6 | 13
> 7 | 2
> 9 | 1
> (8 rows)
> This includes system table and TOAST table indexes (which seem to
> have two columns).
Yeah, TOAST indexes are 2-column. It would be best to exclude those
from your counts, since it seems pretty unlikely that anyone will care
how fast nodeIndexonlyscan.c is for scans on toast tables.
> There are over 400 user tables, each of which
> has a primary key, so most primary keys in our database are more
> than one column.
It doesn't look to me like the mean is above 2 (unless you have many
fewer toast tables than I suspect), so trying to optimize many-column
cases isn't going to help.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2011-10-24 17:52:31 | Re: (PATCH) Adding CORRESPONDING to Set Operations |
Previous Message | Gurjeet Singh | 2011-10-24 17:41:34 | Re: Unreproducible bug in snapshot import code |