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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [PERFORM] Slow count(*) again...
Date: 2011-02-01 22:47:06
Message-ID: 201102012247.p11Ml6u02682@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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. Rather than apply the patch shown above, I'm tempted to think about
> hard-wiring COUNT(*) as a special case in nodeAgg.c such that we don't go
> through advance_aggregates/advance_transition_function at all, but just
> increment a counter directly. However, that would very clearly be
> optimizing COUNT(*) and nothing else. Given the opinions expressed
> elsewhere in this thread that heavy reliance on COUNT(*) represents
> bad application design, I'm not sure that such a patch would meet with
> general approval.
>
> Actually the patch shown above is optimizing COUNT(*) and nothing else,
> too, since it's hard to conceive of any other zero-argument aggregate.
>
> Anyway, if anyone is hot to make COUNT(*) faster, that's where to look.
> I don't think any of the previous discussion in this thread is on-point
> at all, except for the parts where people suggested avoiding it.

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

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-02-01 23:03:39 Re: [PERFORM] Slow count(*) again...
Previous Message Christian Ullrich 2011-02-01 22:17:00 Re: Authentication Enhancement Proposal

Browse pgsql-performance by date

  From Date Subject
Next Message Andrew Dunstan 2011-02-01 23:03:39 Re: [PERFORM] Slow count(*) again...
Previous Message Robert Haas 2011-02-01 22:33:11 Re: Any experience using "shake" defragmenter?