On Fri, Mar 3, 2017 at 3:57 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> I'm not happy with the way this patch can just happen to latch on to a
> path that's not parallel-safe rather than one that is and then just
> give up on a merge join in that case. I already made this argument in
> https://www.postgresql.org/message-id/CA+TgmobdW2au1Jq5L4ySA2ZhqFmA-qNvD7ZFaZbJWm3c0ysWyw@mail.gmail.com
> and my opinion hasn't changed.
I think last time I did not understand the depth of the problem
completely and only fixed from one aspect that in
generate_partial_mergejoin_paths if cheapest_total_inner or
cheapest_startup_inner is not parallel safe then consider the current
path if that are parallel safe and now I got it how it was completely
wrong.
I have one question for fixing it in sort_inner_and_outer, Currently,
we don't consider the parameterized paths for merge join except the
case when cheapest total paths itself is parameterized, So IIUC, for
creating partial path we will check if cheapest_total_inner path is
not parallel safe then we will find cheapest inner parallel safe path
using your new API get_cheapest_parallel_safe_total_inner, and we will
proceed with this paths if this is not directly parameterized by
outer?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com