On Thu, 5 Jan 2023 at 19:14, Ankit Kumar Pandey <itsanki...@gmail.com> wrote: > We are already doing something like I mentioned. > > Consider this example: > > explain SELECT rank() OVER (ORDER BY a), count(*) OVER (ORDER BY a,b) > FROM abcd; > QUERY PLAN > -------------------------------------------------------------------------- > WindowAgg (cost=83.80..127.55 rows=1250 width=24) > -> WindowAgg (cost=83.80..108.80 rows=1250 width=16) > -> Sort (cost=83.80..86.92 rows=1250 width=8) > Sort Key: a, b > -> Seq Scan on abcd (cost=0.00..19.50 rows=1250 width=8) > (5 rows) > > > If it is okay to do extra sort for first window function (rank) here, > why would it be > > any different in case which I mentioned?
We *can* reuse Sorts where a more strict or equivalent sort order is available. The question is how do we get the final WindowClause to do something slightly more strict to save having to do anything for the ORDER BY. One way you might think would be to adjust the WindowClause's orderClause to add the additional clauses, but that cannot be done because that would cause are_peers() in nodeWindowAgg.c to not count some rows as peers when they maybe should be given a less strict orderClause in the WindowClause. It might be possible to adjust create_one_window_path() so that when processing the final WindowClause that it looks at the DISTINCT or ORDER BY clause to see if we can sort on a few extra columns to save having to do any further sorting. We just *cannot* make any adjustments to the WindowClause's orderClause. David
