On Tue, Feb 28, 2017 at 9:28 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Mon, Feb 27, 2017 at 10:27 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> Okay, but in that case don't you think it is better to consider the >> parallel safety of cheapest_total_inner only when we don't find any >> cheap parallel_safe innerpath by reducing the sort keys? > > Well, we can do that but suppose cheapest_total_inner is not parallel > safe and we do not get any parallel safe path which is cheaper than > cheapest_total_inner, then we just end up making the merge join path > with the cheapest parallel safe path but we might have missed some of > the paths whose pathkey is covering more ordered keys. Still, it's > hard to argue what it better because we can always say that if we try > only cheapest parallel safe path we will generate fewer paths. >
I think for now we can keep the parallel safety check for cheapest inner path, though it will be of use only for the very first time we compare the paths in that loop. I am not sure if there is any other better way to handle the same. -- With Regards, Amit Kapila. 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
