Re: So, is COUNT(*) fast now?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: So, is COUNT(*) fast now?
Дата
Msg-id 4364.1319478719@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: So, is COUNT(*) fast now?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: So, is COUNT(*) fast now?
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gurjeet Singh
Дата:
Сообщение: Re: Unreproducible bug in snapshot import code
Следующее
От: "Erik Rijkers"
Дата:
Сообщение: Re: (PATCH) Adding CORRESPONDING to Set Operations