From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Foreign join pushdown vs EvalPlanQual |
Date: | 2015-06-25 06:11:32 |
Message-ID: | 558B9B94.9060000@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2015-06-25 06:59:42 | Re: Improving log capture of TAP tests with IPC::Run |
Previous Message | Fabien COELHO | 2015-06-25 04:53:59 | Re: checkpointer continuous flushing |