Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

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