>>>>> "Heikki" == Heikki Linnakangas <hlinnakangas@vmware.com> writes:
Heikki> Uh, that's ugly. The EXPLAIN out I mean; as an implementationHeikki> detail chaining the nodes might be
reasonable.But the aboveHeikki> gets unreadable if you have more than a few grouping sets.
It's good for highlighting performance issues in EXPLAIN, too.
4096 grouping sets takes about a third of a second to plan and execute,
but something like a minute to generate the EXPLAIN output. However,
for more realistic sizes, plan time is not significant and explain
takes only about 40ms for 256 grouping sets.
(To avoid resource exhaustion issues, we have set a limit of,
currently, 4096 grouping sets per query level. Without such a limit,
it is easy to write queries that would take TBs of memory to parse or
plan. MSSQL and DB2 have similar limits, I'm told.)
>> The ChainAggregate nodes use a tuplestore to communicate with the>> GroupAggregate node at the top of the chain;
theypass through input>> tuples unchanged, and write aggregated result rows to the tuplestore,>> which the top node
thenreturns once it has finished its own result.
Heikki> Hmm, so there's a "magic link" between the GroupAggregate atHeikki> the top and all the ChainAggregates, via
thetuplestore. ThatHeikki> may be fine, we have special rules in passing informationHeikki> between bitmap scan nodes
too.
Eh. It's far from a perfect solution, but the planner doesn't lend itself
to perfect solutions.
Heikki> But rather than chain multiple ChainAggregate nodes, howHeikki> about just doing all the work in the top
GroupAggregatenode?
It was easier this way. (How would you expect to do it all in the top
node when each subset of the grouping sets list needs to see the data
in a different order?)
--
Andrew (irc:RhodiumToad)
