On 9 March 2016 at 04:06, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Mar 7, 2016 at 5:15 PM, David Rowley > <david.row...@2ndquadrant.com> wrote: >> My concerns are: >> 1. Since there's no cheapest_partial_path in RelOptInfo the code is >> currently considering every partial_path for parallel hash aggregate. >> With normal aggregation we only ever use the cheapest path, so this >> may not be future proof. As of today we do only have at most one >> partial path in the list, but there's no reason to code this with that >> assumption. I didn't put in much effort to improve this as I see code >> in generate_gather_paths() which also makes assumptions about there >> just being 1 partial path. Perhaps we should expand RelOptInfo to >> track the cheapest partial path? or maybe allpaths.c should have a >> function to fetch the cheapest out of the list? > > The first one in the list will be the cheapest; why not just look at > that? Sorted partial paths are interesting if some subsequent path > construction step can make use of that sort ordering, but they're > never interesting from the point of view of matching the query's > pathkeys because of the fact that Gather is order-destroying.
In this case a sorted partial path is useful as the partial agg node sits below Gather. The sorted input is very interesting for the partial agg node with a strategy of AGG_SORTED. In most cases with parallel aggregate it's the partial stage that will take the most time, so if we do get pre-sorted partial paths, this will be very good indeed for parallel agg. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
