Postgres Pro
Downloads
Home   >   mailing lists

Re: [HACKERS] why not parallel seq scan for slow functions - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: [HACKERS] why not parallel seq scan for slow functions
Date
Msg-id CAMkU=1zMC1PAjOeFYUifXWpYg4MUo_SrdjWcf-UVRcvKrsnUew@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] why not parallel seq scan for slow functions  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: [HACKERS] why not parallel seq scan for slow functions
List pgsql-hackers
Tree view
On Mon, Jul 10, 2017 at 9:51 PM, Dilip Kumar <dilipbalaut@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
Attachment

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: [HACKERS] Multi column range partition table
Next
From: Mark Rofail
Date:
Subject: Re: [HACKERS] GSoC 2017: Foreign Key Arrays