On 2016/01/29 17:52, Ashutosh Bapat wrote:
On Fri, Jan 29, 2016 at 2:05 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
On 2016/01/29 1:26, Ashutosh Bapat wrote: Here is the summary of changes from the last set of patches
2. Included fix for EvalPlanQual in postgres_fdw - an alternate local path is obtained from the list of paths linked to the joinrel. Since this is done before adding the ForeignPath, we should be a local path available for given join.
I looked at that code in the patch (ie, postgresRecheckForeignScan and the helper function that creates a local join path for a given foreign join path.), briefly. Maybe I'm missing something, but I think that is basically the same as the fix I proposed for addressing this issue, posted before , right?
Yes, although I have added functions to copy the paths, not consider pathkeys and change the relevant members of the paths. Sorry if I have missed giving you due credits.
If so, my concern is, the helper function probably wouldn't extend to the parameterized-foreign-join-path cases, though that would work well for the unparameterized-foreign-join-path cases. We don't support parameterized-foreign-join paths for 9.6?
If we do not find a local path with given parameterization, it means there are other local parameterized paths which are superior to it. This possibly indicates that there will be foreign join parameterised paths which are superior to this parameterized path, so we basically do not create foreign join path with that parameterization.
The latest version of the postgres_fdw join pushdown patch will support only the unparameterized-path case, so we don't have to consider this, but why do you think the superiority of parameterizations is preserved between remote joining and local joining?
Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers