Re: Final Patch for GROUPING SETS - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Final Patch for GROUPING SETS
Date
Msg-id 8761d3is6c.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Final Patch for GROUPING SETS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Final Patch for GROUPING SETS  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Proposal "VACUUM SCHEMA"
Next
From: Alvaro Herrera
Date:
Subject: Re: pgbench -f and vacuum