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
-
Order active window clauses for greater reuse of Sort nodes.
- 728202b63cdc 12.0 landed