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 [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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
