On Mon, Jul 10, 2017 at 9:51 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> > > In below function, we always multiply the target->cost.per_tuple with > path->rows, but in case of gather it should multiply this with > subpath->rows > > apply_projection_to_path() > .... > > path->startup_cost += target->cost.startup - oldcost.startup; > path->total_cost += target->cost.startup - oldcost.startup + > (target->cost.per_tuple - oldcost.per_tuple) * path->rows; > > > So because of this high projection cost the seqpath and parallel path > both have fuzzily same cost but seqpath is winning because it's > parallel safe. > I think you are correct. However, unless parallel_tuple_cost is set very low, apply_projection_to_path never gets called with the Gather path as an argument. It gets ruled out at some earlier stage, presumably because it assumes the projection step cannot make it win if it is already behind by enough. So the attached patch improves things, but doesn't go far enough. Cheers, Jeff
subpath_projection_cost.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
