Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?

Hi KaiGai-san,

On 2015/07/22 16:44, Kouhei Kaigai wrote:
>> 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?

No, what I'm concerned about is the case when scanrelid > 0.

> 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...?

When scanrelid = 0, I think we should run the alternative plans in
ExecScanFetch or somewhere, as you mentioned.

>> 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.

Sorry, I don't understand what you mean.  Maybe I have to learn more
about custom scans/joins, but thanks for the explanation!

Best regards,
Etsuro Fujita