> I intentionally did the nestloop_params substitution after calling
> GetForeignPlan not before. It's not apparent to me why it would be
> useful to do it before, because the FDW is going to have no idea what
> those params represent. (Note that they represent values coming from
> some other, probably local, relation; not from the foreign table.)
Even if the FDW have no idea what they represent, it can identify a
clause of the form Var Operator Param, which allows to store the param
reference (paramid) for retrieving the param value at execution time.
If the chosen best path is a parameterized path that has been built by
the FDW, it allows to push down this restriction.
If this isn't possible, the only way I found to use those clauses
would be at scan time.
Lets's assume atable is a local relation, and aftable is a foreign
table, and the query looks like this:
select * from atable t1 inner join aftable t2 on t1.c1 = t2.c1
The FDW identifies the join clause on its column c1, and build a
parameterized path on this column (maybe because this column is unique
and indexed on the remote side).
The planner chooses this path, building a nested loop rescanning the
foreign table with this parameter value reflecting the outer relation
value (maybe because the local relation's size is much smaller than
the remote relation's size).
In that case, it seems to be of particular importance to have access
to the clause, so that the nested loop can work as intended: avoiding
a full seqscan on the remote side.
Or is there another way to achieve the same goal ?
Regards,
--
Ronan Dunklau
