On Tue, Oct 10, 2017 at 3:15 AM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 10 October 2017 at 01:10, Jeevan Chalke > <jeevan.cha...@enterprisedb.com> wrote: >> Attached new patch set having HEAD at 84ad4b0 with all these review points >> fixed. Let me know if I missed any thanks. > > I've only really skimmed over this thread and only opened the code > enough to extract the following: > > + /* Multiply the costs by partition_wise_agg_cost_factor. */ > + apath->startup_cost *= partition_wise_agg_cost_factor; > + apath->total_cost *= partition_wise_agg_cost_factor; > > I've not studied how all the path plumbing is done, but I think > instead of doing this costing magic we should really stop pretending > that Append/MergeAppend nodes are cost-free. I think something like > charging cpu_tuple_cost per row expected through Append/MergeAppend > would be a better approach to this. > > If you perform grouping or partial grouping before the Append, then in > most cases the Append will receive less rows, so come out cheaper than > if you perform the grouping after it. I've not learned the > partition-wise join code enough to know if this is going to affect > that too, but for everything else, there should be no plan change, > since there's normally no alternative paths. I see there's even a > comment in create_append_path() which claims the zero cost is a bit > optimistic. >
+1. Partition-wise join will also benefit from costing Append processing. Number of rows * width of join result compared with the sum of that measure for joining relations decides whether Append node processes more data in Append->Join case than Join->Append case. Append node just returns the result of ExecProcNode(). Charging cpu_tuple_cost may make it too expensive. In other places where we charge cpu_tuple_cost there's some processing done to the tuple like ExecStoreTuple() in SeqNext(). May be we need some other measure for Append's processing of the tuple. May be we should try to measure the actual time spent in Append node as a fraction of say time spent in child seq scans. That might give us a clue as to how Append processing can be charged in terms of costing. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
