Re: Foreign join pushdown vs EvalPlanQual

On Mon, Dec 7, 2015 at 12:25 AM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Instead, I think we should go the opposite direction and pass the
>> outerplan to GetForeignPlan after all. I was lulled into a full sense
>> of security by the realization that every FDW that uses this feature
>> MUST want to do outerPlan(scan_plan) = fdw_outerplan. That's true,
>> but irrelevant. The point is that the FDW might want to do something
>> additional, like frob the outer plan's tlist, and it can't do that if
>> we don't pass it fdw_outerplan. So we should do that, after all.
>
> As I proposed upthread, another idea would be to 1) to store an
> fdw_outerpath in the fdw_private list of a ForeignPath node, and then 2) to
> create an fdw_outerplan from *the fdw_outerpath stored into
> the fdw_private* in GetForeignPlan. One good thing for this is that we keep
> the API of create_foreignscan_path as-is. What do you think about that?

I don't think it's a good idea, per what I said in the first paragraph
of this email:

http://www.postgresql.org/message-id/CA+TgmoZ5G+ZGPh3STMGM6cWgTOywz3N1PjSw6Lvhz31ofgLZVw@mail.gmail.com

I think the core system likely needs visibility into where paths and
plans are present in node trees, and putting them somewhere inside
fdw_private would be going in the opposite direction.

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