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. 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?
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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
