Re: Final Patch for GROUPING SETS

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

[Noah]
>> I caution against using window function performance as the
>> template for GROUPING SETS performance goals. The benefit of
>> GROUPING SETS compared to its UNION ALL functional equivalent is
>> 15% syntactic pleasantness, 85% performance opportunities.
>> Contrast that having window functions is great even with naive
>> performance, because they enable tasks that are otherwise too hard
>> in SQL.

Yes, this is a reasonable point.

Tom> The other reason that's a bad comparison is that I've not seen
Tom> many queries that use more than a couple of window frames,
Tom> whereas we have to expect that the number of grouping sets in
Tom> typical queries will be significantly more than "a couple".

I would be interested in seeing more good examples of the size and
type of grouping sets used in typical queries.

Tom> So we do have to think about what the performance will be like
Tom> with a lot of sort steps. I'm also worried that this use-case
Tom> may finally force us to do something about the "one work_mem per
Tom> sort node" behavior, unless we can hack things so that only one
Tom> or two sorts reach max memory consumption concurrently.

Modifying ChainAggregate so that only two sorts reach max memory
consumption concurrently seems to have been quite simple to implement,
though I'm still testing some aspects of it.

--
Andrew (irc:RhodiumToad)