On Sat, Feb 13, 2016 at 3:51 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sun, Feb 7, 2016 at 8:21 PM, Haribabu Kommi
> <kommi.haribabu@gmail.com> wrote:future.
>> Here I attached updated patch with the corrections.
>
> So, what about the main patch, for parallel aggregation itself? I'm
> reluctant to spend too much time massaging combine functions if we
> don't have the infrastructure to use them.
Here I attached a draft patch based on previous discussions. It still needs
better comments and optimization.
Overview:
1. Before creating the plan for the best path, verify whether parallel aggregate
plan is possible or not? If possible check whether it is the cheapest plan
compared to normal aggregate? If parallel is cheaper then replace the best
path with the cheapest_partial_path.
2. while generating parallel aggregate plan, first generate targetlist of
partial aggregate by generating bare aggregate references and group by
expressions.
3. Change the aggref->aggtype with aggtranstype in the partial aggregate
targetlist to return a proper tuple data from worker.
4. Generate partial aggregate node using the generated targetlist.
5. Add gather and finalize aggregate nodes on top of partial aggregate plan.
To do:
1. Optimize the aggregate cost calculation mechanism, currently it is used
many times.
2. Better comments and etc.
Please verify whether the patch is in the right direction as per your
expectation?
Regards,
Hari Babu
Fujitsu Australia