Re: Foreign join pushdown vs EvalPlanQual - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Foreign join pushdown vs EvalPlanQual
Date
Msg-id 558B9B94.9060000@lab.ntt.co.jp
Whole thread Raw
In response to Re: Foreign join pushdown vs EvalPlanQual  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Responses Re: Foreign join pushdown vs EvalPlanQual  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List pgsql-hackers
Hi KaiGai-san,

I'd like to work on this issue with you!

On 2015/06/25 10:48, Kouhei Kaigai wrote:
> I'd like to suggest a solution that re-construct remote tuple according
> to the fdw_scan_tlist on ExecScanFetch, if given scanrelid == 0.
> It enables to run local qualifier associated with the ForeignScan node,
> and it will also work for the case when tuple in es_epqTupleSet[] was
> local heap.

Maybe I'm missing something, but I don't think your proposal works 
properly because we don't have any component ForeignScan state node or 
subsidiary join state node once we've replaced the entire join with the 
ForeignScan performing the join remotely, IIUC.  So, my image was to 
have another subplan for EvalPlanQual as well as the ForeignScan, to do 
the entire join locally for the component test tuples if we are inside 
an EvalPlanQual recheck.

> BTW, if you try newer version of postgres_fdw foreign join patch,
> please provide me to reproduce the problem/

OK

> Also, as an aside, postgres_fdw does not implement RefetchForeignRow()
> at this moment. Does it make a problem?

I don't think so, though I think it would be better to test that the 
foreign join pushdown API patch also allows late row locking using the 
postgres_fdw.

Best regards,
Etsuro Fujita



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: "Erik Rijkers"
Date:
Subject: Re: Improving log capture of TAP tests with IPC::Run