Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] Slow count(*) again...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [PERFORM] Slow count(*) again...
Date: 2011-02-01 23:12:44
Message-ID: 5100.1296601964@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 02/01/2011 05:47 PM, Bruce Momjian wrote:
>> Tom Lane wrote:
>>> At this point what we've got is 25% of the runtime in nodeAgg.c overhead,
>>> and it's difficult to see how to get any real improvement without tackling
>>> that.

>> Do we want a TODO about optimizing COUNT(*) to avoid aggregate
>> processing overhead?

> Whether or not it's bad application design, it's ubiquitous, and we 
> should make it work as best we can, IMNSHO. This often generates 
> complaints about Postgres, and if we really plan for world domination 
> this needs to be part of it.

I don't think that saving ~25% on COUNT(*) runtime will help that at all.
The people who complain about it expect it to be instantaneous.

If this sort of hack were free, I'd be all for doing it anyway; but I'm
concerned that adding tests to enable a fast path will slow down every
other aggregate, or else duplicate a lot of code that we'll then have to
maintain.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Mladen GogalaDate: 2011-02-01 23:21:04
Subject: Re: [PERFORM] Slow count(*) again...
Previous:From: Andrew DunstanDate: 2011-02-01 23:03:39
Subject: Re: [PERFORM] Slow count(*) again...

pgsql-hackers by date

Next:From: Mladen GogalaDate: 2011-02-01 23:21:04
Subject: Re: [PERFORM] Slow count(*) again...
Previous:From: Thom BrownDate: 2011-02-01 23:08:55
Subject: Re: Issues with generate_series using integer boundaries

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group