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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
