Re: Final Patch for GROUPING SETS

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Greg Stark <stark(at)mit(dot)edu>, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Svenne Krap <svenne(at)krap(dot)dk>
Subject: Re: Final Patch for GROUPING SETS
Date: 2015-05-13 07:04:41
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>>>>> "Andres" == Andres Freund <andres(at)anarazel(dot)de> writes:

Andres> Andrew, are you going to be working on any of these?

As discussed on IRC, current status is:

>>> * The increased complexity of grouping_planner. It'd imo be good if some
>>> of that could be refactored into a separate function. Specifically the
>>> else if (parse->hasAggs || (parse->groupingSets && parse->groupClause))
>>> block.

done and pushed at you

>>> * The Hopcroft-Karp stuff not being separate

done and pushed

Andres> * to split agg_retrieve_direct into a version for grouping sets
Andres> and one without. I think that'll be a pretty clear win for
Andres> clarity.

I don't see how this helps given that the grouping sets version will be
exactly as complex as the current code.

Andres> * to spin out common code between agg_retrieve_direct (in both
Andres> the functions its split into), agg_retrieve_hashed and
Andres> agg_retrieve_chained. It should e.g. be fairly simple to spin
Andres> out the tail end processing of a input group
Andres> (finalize_aggregate loop, ExecQual) into a separate function.

This isn't _quite_ as simple as it sounds but I'll have a go.

>> * The code in nodeAgg.c isn't pretty in places. Stuff like if
>> (node->chain_depth > 0) estate->agg_chain_head = save_chain_head;...
>> Feels like a good bit of cleanup would be possible there.

I'll look.

Andrew (irc:RhodiumToad)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2015-05-13 07:25:52 Re: EvalPlanQual behaves oddly for FDW queries involving system columns
Previous Message Pavel Stehule 2015-05-13 06:32:17 Re: proposal: contrib module - generic command scheduler