Horton

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

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mladen Gogala <mladen.gogala@vmsinfo.com>, "david@lang.hm" <david@lang.hm>, Craig Ringer <craig@postnewspapers.com.au>, Vitalii Tymchyshyn <tivv00@gmail.com>, PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: 2011-02-01T22:47:06Z
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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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