On Wed, Jul 12, 2017 at 10:55 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > 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.
Patch looks good to me. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
