On Fri, Mar 3, 2017 at 3:57 PM, Robert Haas <robertmh...@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-qnvd7zfazbjwm3c0ys...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
