On Sat, Feb 13, 2016 at 3:51 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Feb 7, 2016 at 8:21 PM, Haribabu Kommi > <kommi.harib...@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
Description: Binary data
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers