>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
