Re: Foreign join pushdown vs EvalPlanQual

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

In response to

Responses

Browse pgsql-hackers by date

  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