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

From Andrew Gierth
Subject Re: Final Patch for GROUPING SETS
Date
Msg-id 87y4ktc7za.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Final Patch for GROUPING SETS  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
>>>>> "Andres" == Andres Freund <andres@anarazel.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
separatefunction. 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 setsAndres> and one without. I think that'll be a
prettyclear win forAndres> 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 bothAndres> the functions its split into),
agg_retrieve_hashedandAndres> agg_retrieve_chained. It should e.g. be fairly simple to spinAndres> out the tail end
processingof a input groupAndres> (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)



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: contrib module - generic command scheduler
Next
From: Etsuro Fujita
Date:
Subject: Re: EvalPlanQual behaves oddly for FDW queries involving system columns