Re: Aggregate node doesn't include cost for sorting

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> So, with the assumption that you've used 2 different versions to show
> this output, for post 1349d279, there does not seem to be much choice
> on how the aggregate is executed. What's your concern about the
> costings having to be accurate given there's no other plan choice?

It's true that the cost attributed to the Agg node won't impact any
live decisions in the plan level in which it appears. However, if
that's a subquery, then the total cost attributed to the subplan
could in principle affect plan choices in the outer query. So there
is a valid argument for wanting to try to get it right.

Having said that, I think that the actual impact on outer-level choices
is usually minimal. So it didn't bother me that we swept this under
the rug before --- and I'm pretty sure that we're sweeping similar
things under the rug elsewhere in top-of-query planning. However,
given 1349d279 it should surely be true that the planner knows how many
sorts it's left to be done at runtime (a number we did not have at hand
before). So it seems like it ought to be simple enough to account for
this effect more accurately. I'd be in favor of doing so if it's
simple and cheap to get the numbers.

regards, tom lane