Gregory Stark <stark@enterprisedb.com> writes:
> I don't understand why it wouldn't work to do it for any arbitrary path for
> any query at all as long as it has the correct ordering.
It might work, but the resulting plan would be uniformly inferior to the
regular aggregate code. The only case where the optimization is a win
is where you have a zero-startup-cost subplan, and the only way to get
sorted output with zero startup cost is an indexscan. Anything
involving a sort will be a loser, or at best break-even if the sort
figures out it can use top-N.
> I would have expected the way to do this would be to detect that the min/max
> optimization might be applicable early on, in which case we teach
> pathkeys_useful_for_ordering about the ordering which would be necessary for
> it.
Possibly. I did it the way I did mostly to minimize the side-effects on
the rest of the planner. But I think if we did it like that, we'd waste
cycles considering ordered-output paths that are really not of any value
in light of the comments above.
regards, tom lane
