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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
