Re: Foreign join pushdown vs EvalPlanQual

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: Foreign join pushdown vs EvalPlanQual
Дата
Msg-id 558B9B94.9060000@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Foreign join pushdown vs EvalPlanQual  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Ответы Re: Foreign join pushdown vs EvalPlanQual
Список 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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Support for N synchronous standby servers - take 2
Следующее
От: "Erik Rijkers"
Дата:
Сообщение: Re: Improving log capture of TAP tests with IPC::Run