Re: Slow count(*) again...

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Slow count(*) again...
Дата
Msg-id 4292.1286909893@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Slow count(*) again...  (Jesper Krogh <jesper@krogh.cc>)
Ответы Re: Slow count(*) again...
Re: Slow count(*) again...
Список pgsql-performance
Jesper Krogh <jesper@krogh.cc> writes:
> On 2010-10-12 19:07, Tom Lane wrote:
>> Anyway, if anyone is hot to make COUNT(*) faster, that's where to look.

> Just having 32 bytes bytes of "payload" would more or less double
> you time to count if I read you test results correctly?. .. and in the
> situation where diskaccess would be needed .. way more.

> Dividing by pg_relation_size by the amout of tuples in our production
> system I end up having no avg tuple size less than 100bytes.

Well, yeah.  I deliberately tested with a very narrow table so as to
stress the per-row CPU costs as much as possible.  With any wider table
you're just going to be I/O bound.

> .. without having complete insigt.. a visibillity map that could be used in
> conjunction with indices would solve that. What the cost would be
> of maintaining it is also a factor.

I'm less than convinced that that approach will result in a significant
win.  It's certainly not going to do anything to convert COUNT(*) into
an O(1) operation, which frankly is what the complainants are expecting.
There's basically no hope of solving the "PR problem" without somehow
turning COUNT(*) into a materialized-view reference.  We've discussed
that in the past, and know how to do it in principle, but the complexity
and distributed overhead are daunting.

            regards, tom lane

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

Предыдущее
От: Jesper Krogh
Дата:
Сообщение: Re: Slow count(*) again...
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: read only transactions