On Wed, Jul 12, 2017 at 1:50 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Mon, Jul 10, 2017 at 9:51 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: >> >> 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. >
I think that is genuine because tuple communication cost is very high. If your table is reasonable large then you might want to try by increasing parallel workers (Alter Table ... Set (parallel_workers = ..)) > So the attached patch improves things, but doesn't go far enough. > It seems to that we need to adjust the cost based on if the below node is projection capable. See attached. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
subpath_projection_cost.2.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
