Re: Final Patch for GROUPING SETS
От | Andrew Gierth |
---|---|
Тема | Re: Final Patch for GROUPING SETS |
Дата | |
Msg-id | 8761d3is6c.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Final Patch for GROUPING SETS (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Final Patch for GROUPING SETS
|
Список | pgsql-hackers |
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: [Noah]>> I caution against using window function performance as the>> template for GROUPING SETS performance goals. Thebenefit of>> GROUPING SETS compared to its UNION ALL functional equivalent is>> 15% syntactic pleasantness, 85% performanceopportunities.>> Contrast that having window functions is great even with naive>> performance, because they enabletasks 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 seenTom> many queries that use more than a couple of windowframes,Tom> whereas we have to expect that the number of grouping sets inTom> typical queries will be significantlymore 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 likeTom> with a lot of sort steps. I'm also worried thatthis use-caseTom> may finally force us to do something about the "one work_mem perTom> sort node" behavior, unless wecan hack things so that only oneTom> 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)
В списке pgsql-hackers по дате отправления: