Re: Slow count(*) again...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jesper Krogh <jesper(at)krogh(dot)cc>
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-12 18:58:13
Message-ID: 4292.1286909893@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Jesper Krogh <jesper(at)krogh(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2010-10-12 19:17:47 Re: ISN patch that applies cleanly with git apply
Previous Message Dimitri Fontaine 2010-10-12 18:57:09 Extensions, this time with a patch

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2010-10-12 19:33:44 Re: read only transactions
Previous Message Jesper Krogh 2010-10-12 18:22:01 Re: Slow count(*) again...