On Thu, Jan 19, 2017 at 2:14 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jan 13, 2017 at 6:22 AM, Etsuro Fujita > <fujita.ets...@lab.ntt.co.jp> wrote: >> My biggest concern about GetExistingLocalJoinPath is that might not be >> extendable to the case of foreign-join paths with parameterization; in which >> case, fdw_outerpath for a given foreign-join path would need to have the >> same parameterization as the foreign-join path, but there might not be any >> existing paths with the same parameterization in the path list. > > I agree that this is a problem.
Effectively, it means that foreign join path creation will have a parameterization different (per add_path()) from any local join produced. But why would it be so? The parameterization bubbles up from the base relation. The process for creating parameterized local and foreign paths for a base relation is same. Thus we will have same parameterizations considered for foreign as well as local joins. Those different parameterizations will be retained add_path(), so we should find one there or should be able to expand an existing parameterization by reparameterization. Even if such a case exists, the same problem exists while searching paths from the joining relations. If the join doesn't have a local path with required parameterization, so would be the joining relations, parameterized paths from which are used to build parameterized paths for join. > >> You might >> think we could get the fdw_outerpath by getting an existing path with no >> parameterization as in GetExistingLocalJoinPath and then modifying the >> path's param_info to match the parameterization of the foreign-join path. I >> don't know that really works, but that might be inefficient. > > I am not sure about this. > >> What I have in mind to support foreign-join paths with parameterization for >> postgres_fdw like this: (1) generate parameterized paths from any joinable >> combination of the outer/inner cheapest-parameterized paths that have pushed >> down the outer/inner relation to the remote server, in a similar way as >> postgresGetForeignJoinPaths creates unparameterized paths, and (2) create >> fdw_outerpath for each parameterized path from the outer/inner paths used to >> generate the parameterized path, by create_nestloop_path (or, >> create_hashjoin_path or create_mergejoin_path if full join), so that the >> resulting fdw_outerpath has the same parameterization as the paramterized >> path. This would probably work and might be more efficient. And the patch >> I proposed would be easily extended to this, by replacing the outer/inner >> cheapest-total paths with the outer/inner cheapest-parameterized paths. >> Attached is the latest version of the patch. > > Yes, I think that's broadly the approach Tom was recommending. I don't have problem with that approach, but the latest patch has following problems. 1. We are copying chunks of path creation logic, instead of reusing corresponding functions. 2. There are many cases where the new function would return no local path and hence postgres_fdw doesn't push down the join . This will be performance regression compared to 9.6.  https://firstname.lastname@example.org/msg302463.html -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers