Re: Foreign join pushdown vs EvalPlanQual

On 2015/09/29 17:49, Kouhei Kaigai wrote:
>> From: pgsql-hackers-owner@postgresql.org
>> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Etsuro Fujita

>>> RefetchForeignRow() does not take ForeignScanState as its argument,
>>> so it is not obvious to access its private field, isn't it?
>>> ExecRowMark contains "rti" field, so it might be feasible to find out
>>> the target PlanState using walker routine recently supported, although
>>> it is not a simple enough.
>>> Unless we don't have reference to the private field, it is not feasible
>>> to access expression that was pushed down to the remote-side, therefore,
>>> it does not allow to apply proper rechecks here.

>>> Could you introduce us (1) how to access private data field of
>>> ForeignScanState from the RefetchForeignRow callback?

>> For the foreign table case (scanrelid>0), I imagined an approach
>> different than yours.  In that case, I thought the issue would be
>> probably addressed by just modifying the remote query performed in
>> RefetchForeignRow, which would be of the form "SELECT ctid, * FROM
>> remote table WHERE ctid = $1", so that the modified query would be of
>> the form "SELECT ctid, * FROM remote table WHERE ctid = $1 AND *remote
>> quals*".

Sorry, I forgot to add "FOR UPDATE" to the before/after queries.

> My question is how to pull expression of the remote query.
> It shall be stored at somewhere private field of ForeignScanState,
> however, RefetchForeignRow does not have direct access to the
> relevant ForeignScanState node.
> It is what I asked at the question (1).

I imagined the following steps to get the remote query string: (1) 
create the remote query string and store it in fdw_private during 
postgresGetForeignPlan, (2) extract the string from fdw_private and 
store it in erm->ermExtra during postgresBeginForeignScan, and (3) 
extract the string from erm->ermExtra in postgresRefetchForeignRow.

> Also note that EvalPlanQualFetchRowMarks() will raise an error
> if RefetchForeignRow callback returned NULL tuple.
> Is it right or expected behavior?

IIUC, I think that that behavior is reasonable.

> It looks to me this callback is designed to pull out a particular
> tuple identified by the remote-row-id, regardless of the qualifier
> checks based on the latest value.

Because erm->markType==ROW_MARK_REFERENCE, I don't think that that 
behavior would cause any problem.  Maybe I'm missing something, though.

Best regards,
Etsuro Fujita