Re: [HACKERS] Partition-wise aggregation/grouping
От | Antonin Houska |
---|---|
Тема | Re: [HACKERS] Partition-wise aggregation/grouping |
Дата | |
Msg-id | 4127.1493202482@localhost обсуждение исходный текст |
Ответ на | [HACKERS] Partition-wise aggregation/grouping (Jeevan Chalke <jeevan.chalke@enterprisedb.com>) |
Ответы |
Re: [HACKERS] Partition-wise aggregation/grouping
|
Список | pgsql-hackers |
Antonin Houska <ah@cybertec.at> wrote: > Antonin Houska <ah@cybertec.at> wrote: > > > > Jeevan Chalke <jeevan.chalke@enterprisedb.com> wrote: > > > > > Our work will overlap when we are pushing down the aggregate on partitioned > > > base relation to its children/partitions. > > > > > > I think you should continue working on pushing down aggregate onto the > > > joins/scans where as I will continue my work on pushing down aggregates to > > > partitions (joins as well as single table). Once we are done with these task, > > > then we may need to find a way to integrate them. > > > > > > [1] https://www.postgresql.org/message-id/flat/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com#CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com > > > > My patch does also create (partial) aggregation paths below the Append node, > > but only expects SeqScan as input. Please check if you patch can be based on > > this or if there's any conflict. > > Well, I haven't imposed any explicit restriction on the kind of path to be > aggregated below the Append path. Maybe the only thing to do is to merge my > patch with the "partition-wise join" patch (which I haven't checked yet). Attached is a diff that contains both patches merged. This is just to prove my assumption, details to be elaborated later. The scripts attached produce the following plan in my environment: QUERY PLAN ------------------------------------------------ Parallel Finalize HashAggregate Group Key: b_1.j -> Append -> Parallel Partial HashAggregate Group Key: b_1.j -> Hash Join Hash Cond: (b_1.j = c_1.k) -> Seq Scan on b_1 -> Hash -> Seq Scan on c_1 -> Parallel Partial HashAggregate Group Key: b_2.j -> Hash Join Hash Cond: (b_2.j = c_2.k) -> Seq Scan on b_2 -> Hash -> Seq Scan on c_2 Note that I had no better idea how to enforce the plan than hard-wiring zero costs of the partial aggregation paths. This simulates the use case of partial aggregation performed on remote node (postgres_fdw). Other use cases may exist, but I only wanted to prove the concept in terms of coding so far. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: