One question that arose in my mind running this was whether might be able to combine sum(x) with count(*) if x was NOT NULL, even though the arguments don't match. It might not be worth the gymnastics of recognizing the special case, and I certainly wouldn't recommend looking at that optimization in a first pass; but it might be worth jotting down on a list somewhere....
I'm just not so sure what the logic would be to decide when we could apply this. The only properties I can see that may be along the right lines are pg_proc.pronargs for int8inc and inc8inc_any.
Actually a possible realistic solution to this just came to me.
Add another property to pg_aggregate which stores the oid of an alternative aggregate function which can be used when all arguments to the transition function can be proved to be not null. This of course would be set to InvalidOid in most cases.
But at least one good usage case would be COUNT(not_null_expr) would use COUNT(*).
This likely could not be applied if DISTINCT or ORDER BY were used.
I'm not proposing that we go and do this. More analysis would have to be done to see if the trade offs between extra code, extra planning time produce a net win overall. The aggregate code has already gotten quite a bit more complex over the past couple of releases.
