Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it? - Mailing list pgsql-hackers

From Kouhei Kaigai
Subject Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?
Date
Msg-id 9A28C8860F777E439AA12E8AEA7694F80111B1C7@BPXM15GP.gisp.nec.co.jp
Whole thread Raw
In response to fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?
List pgsql-hackers
Fujita-san,

Sorry for my late response.

> The latest foreign-join pushdown patch allows fdw_scan_tlist to be set
> to a targetlist even for simple foreign table scans.  However, since I
> think we assume that the test tuple of a foreign table for an EPQ
> testing, whether it may be copied from the whole-row var or returned by
> the RefetchForeignRow routine, has the rowtype declared for the foreign
> table, ISTM that EPQ testing doesn't work properly in such a case since
> that the targetlist and qual are adjusted to reference fdw_scan_tlist in
> such a case.  Maybe I'm missing something though.
>
Let me confirm step-by-step.
For EPQ testing, whole-row-reference or RefetchForeignRow pulls a record
with row-type compatible to the base foreign table. Then, this record
is stored in the es_epqTuple[] indexed by the base relation.

According to the previous discussion, I expect these tuples are re-checked
by built-in execution plan, but equivalent to the sub-plan entirely pushed
out to the remote side.
Do we see the same assumption?

If so, next step is enhancement of ExecScanFetch() to run the alternative
built-in plans towards each es_epqTuple[] records, if given scanrelid==0.
In this case, expression nodes adjusted to fdw_scan_tlist never called,
so it should not lead any problems...?

> I don't understand custom scans/joins exactly, but I have a similar
> concern for the simple-custom-scan case too.
>
In case of custom scan/join, it fetches a record using heap_fetch()
identified by ctid, and saved to es_epqTuple[].
Then, EvalPlanQual() walks down the plan-tree. Once it appears a node
of custom-join (scanrelid==0), it shall call the equivalent alternatives
if possible, or calls ExecProcNode() towards the underlying nodes then
re-construct its result according to the custom_scan_tlist definition.

It does not look to me problematic.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Use pg_rewind when target timeline was switched
Next
From: Simon Riggs
Date:
Subject: Re: WAL logging problem in 9.4.3?