On Fri, Jan 6, 2017 at 6:31 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > On 2017/01/05 12:10, Etsuro Fujita wrote: >> >> On 2016/12/28 17:34, Ashutosh Bapat wrote: >>> >>> Hmm. If I understand the patch correctly, it does not return any path >>> when merge join is allowed and there are merge clauses but no hash >>> clauses. In this case we will not create a foreign join path, loosing >>> some optimization. If we remove GetExistingLocalJoinPath, which >>> returns a path in those cases as well, we have a regression in >>> performance. > > >> Ok, will revise, but as I mentioned upthread, I'm not sure it's a good >> idea to search the pathlist to get a merge join even in this case. I'd >> vote for creating a merge join path from the inner/outer paths in this >> case as well. > > > Done. Attached is the new version of the patch. > > * I'm still not sure the search approach is the right way to go, so I > modified CreateLocalJoinPath so that it creates a mergejoin path that > explicitly sorts both the outer and inner relations as in > sort_inner_and_outer, by using the information saved in that function. I > think we could try to create a sort-free mergejoin as in > match_unsorted_outer, but I'm not sure it's worth complicating the code. > * I modified CreateLocalJoinPath so that it handles the cheapest-total paths > for the outer/inner relations that are parameterized if possible. > * I adjusted the code and revised some comments. > > As I said upthread, we could skip costing for a local join path in > CreateLocalJoinPath, for efficiency, but I'm not sure we should do that.
CreateLocalJoinPath tries to construct a nestloop path for the given join relation because it wants to avoid merge/hash join paths which require expensive setup not required for EPQ. But it chooses cheap paths for joining relations which may not be nestloop paths. So, effectively it could happen that the whole alternate local plan would be filled with hash/merge joins except the uppermost join. Or it can have foreign paths in there, which will need redirection. That's not very good. Neither it's good to start constructing a nestloop join tree top to bottom every time. We have to choose one of the following alternatives 1. develop a mechanism to remember epq path for joining relations so that it's available to CreateLocalJoinPath 2.let the caller pass epq local paths for joining relations to CreateLocalJoinPath. How it remembers those, is FDW's problem. 2. Fix existing code by applying patch from [1] [1] https://www.postgresql.org/message-id/cafjfprd9ozekur9aormh2toxq4nyuusw2kb9s%2bo%3duvz4xcr%3...@mail.gmail.com -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
