Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused
| От | Tom Lane | 
|---|---|
| Тема | Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused | 
| Дата | |
| Msg-id | 1400.1536799106@sss.pgh.pa.us обсуждение исходный текст | 
| Ответ на | Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused (Andrew Gierth <andrew@tao11.riddles.org.uk>) | 
| Список | 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
		
	В списке pgsql-hackers по дате отправления: