Re: Foreign join pushdown vs EvalPlanQual

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Robert Haas
> Sent: Tuesday, September 29, 2015 5:46 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Etsuro Fujita; PostgreSQL-development; 花田茂
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> On Mon, Sep 28, 2015 at 3:34 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> > The attached patch allows FDW driver to handle EPQ recheck by its own
> > preferable way, even if it is alternative local join or ExecQual to
> > the expression being pushed down.
>
> Thanks. I was all set to commit this, or at least part of it, when I
> noticed that we already have an FDW callback called RefetchForeignRow.
> We seem to be intending that this new callback should refetch the row
> from the foreign server and verify that any pushed-down quals apply to
> it. But why can't RefetchForeignRow do that? That seems to be what
> it's for.
>
At least here are two matters to solve the problem with RefetchForeignRow.

1. RefetchForeignRow() does not take ForeignScanState argument, so it is
not obvious how to cooperate with the private state in ForeignScanState;
that may include expression pushed down, and so on.

2. ForeignScan with scanrelid == 0 represents the result of joined
relations. Even if the refetched tuple is visible on base-relation
level, it may not survive the join condition at the upper level.
Once relations join get pushed down, only FDW driver knows how
base relations are joined.

So, it is the only reasonable way to ask FDW driver on ExecScanFetch,
to check visibility of a particular tuple or another tuple made from
this.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>