Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused

Andrew Gierth  writes:
> (aside: I itch to rewrite the comment that says "the spec requires that
> there be only one sort" - number of sorts is an implementation detail
> about which the spec is silent, what it _actually_ requires is that peer
> rows must be presented in the same order in all order-equivalent
> windows, which we choose to implement by ensuring there is only one sort
> for such windows, rather than, for example, adding extra sort keys to
> provide stability.)

Sure, rewrite away.

> (Perhaps worth noting for future work is that this code and the grouping
> sets code have a common issue: currently we allow only one sort order to
> be requested as query_pathkeys, but this means that both window paths
> and grouping sets paths have to make an essentially arbitrary choice of
> query_pathkeys, rather than having a set of possible "useful" orderings
> and taking whichever can be produced most cheaply.)

Yeah, I've had a bee in my bonnet for awhile about replacing
query_pathkeys with a list of potentially-desirable result orderings.
So far there hasn't been a truly compelling reason to do it, but if
somebody felt like generalizing the window function ordering stuff
in that direction, it'd be a nice project.

			regards, tom lane