On 2016/01/29 17:52, Ashutosh Bapat wrote:
> On Fri, Jan 29, 2016 at 2:05 PM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp <mailto:fujita.etsuro@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 [1], 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
