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: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it? |
Date: | 2015-07-22 10:05:05 |
Message-ID: | 55AF6AD1.50301@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Thakur, Sameer | 2015-07-22 10:09:33 | Re: [PROPOSAL] VACUUM Progress Checker. |
Previous Message | Heikki Linnakangas | 2015-07-22 08:37:29 | Re: polymorphic types - enforce casting to most common type automatically |