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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Daniel Gustafsson <daniel@yesql.se>, Masahiko Sawada <sawada.mshk@gmail.com>, Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-09-13T00:38:26Z
Lists: pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> * I'm almost thinking that changing to list_union is a bad idea,

> A fair point. Though it looks like list_union is used in only about 3
> distinct places, and two of those are list_union(NIL, blah) to simply
> remove dups from a single list. The third place is the cartesian-product
> expansion of grouping sets, which uses list_union_int to remove
> duplicates - changing the order there will give slightly user-surprising
> but not actually incorrect results.

> Presumably list_concat_unique should be considered to guarantee that it
> preserves the relative order of the two lists and of the non-duplicate
> items in the second list?

I'm thinking that whichever coding we use, the patch should include
comment additions in list.c documenting that some callers have assumptions
thus-and-so about list order preservation.  Then at least anybody who
got the idea to try to improve performance of those functions would be on
notice about the risks.

I see that list_union is currently documented like this:

 * Generate the union of two lists. This is calculated by copying
 * list1 via list_copy(), then adding to it all the members of list2
 * that aren't already in list1.

so as long as it stays like that, it's not unreasonable to use it in
this patch.  I just want the potential landmine to be obvious at that
end.

			regards, tom lane


Commits

  1. Order active window clauses for greater reuse of Sort nodes.