Re: Foreign join pushdown vs EvalPlanQual

On Thu, Oct 29, 2015 at 6:05 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> In this case, the EPQ slot to store the joined tuple is still
> a challenge to be solved.
>
> Is it possible to use one or any of EPQ slots that are setup for
> base relations but represented by ForeignScan/CustomScan?

Yes, I proposed that exact thing upthread.

> In case when ForeignScan run a remote join that involves three
> base foreign tables (relid=2, 3, 5 for example), for example,
> no other code touches this slot. So, it is safe even if we put
> a joined tuple on EPQ slots of underlying base relations.
>
> In this case, EPQ slots are initialized as below:
>
> es_epqTuple[0] ... EPQ tuple of base relation (relid=1)
> es_epqTuple[1] ... EPQ of the joined tuple (for relis=2, 3 5)
> es_epqTuple[2] ... EPQ of the joined tuple (for relis=2, 3 5), copy of above
> es_epqTuple[3] ... EPQ tuple of base relation (relid=4)
> es_epqTuple[4] ... EPQ of the joined tuple (for relis=2, 3 5), copy of above
> es_epqTuple[5] ... EPQ tuple of base relation (relid=6)

You don't really need to initialize them all. You can just initialize
es_epqTuple[1] and leave 2 and 4 unused.

> Then, if FDW/CSP is designed to utilize the preliminary joined
> tuples rather than local join, it can just raise the tuple kept
> in one of the EPQ slots for underlying base relations.
> If FDW/CSP prefers local join, it can perform as like local join
> doing; check join condition and construct a joined tuple by itself
> or by alternative plan.

Right.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company