Re: We need to support ForeignRecheck for late row locking, don't we?

On 2015/07/27 18:16, Kouhei Kaigai wrote:
>> On 2015/07/24 23:51, Kouhei Kaigai wrote:
>>>> On 2015/07/22 19:10, Etsuro Fujita wrote:
>>>>> While working on the issue "Foreign join pushdown vs EvalPlanQual", I
>>>>> happened to notice odd behaviors of late row locking in FDWs.
>>>>
>>>>> I think the reason for that is because we don't check pushed-down quals
>>>>> inside an EPQ testing even if what was fetched by RefetchForeignRow was
>>>>> an updated version of the tuple rather than the same version previously
>>>>> obtained. So, to fix this, I'd like to propose that pushed-down quals
>>>>> be checked in ForeignRecheck.
>>
>>>> * I've modified ForeignRecheck so as to check pushed-down quals whether
>>>> doing late locking or early locking.
>>
>>> Isn't it an option to put a new callback in ForeignRecheck?
>>>
>>> FDW driver knows its private data structure includes expression node
>>> that was pushed down to the remote side. So, it seems to me the best
>>> way to consult FDW driver whether the supplied tuple should be visible
>>> according to the pushed down qualifier.
>>>
>>> More or less, this fix need a new interface contract around EvalPlanQual
>>> logic. It is better to give FDW driver more flexibility of its private
>>> data structure and the way to process recheck logic, rather than special
>>> purpose variable.
>>>
>>> If FDW driver managed pushed-down expression in its own format, requirement
>>> to pushedDownQual makes them to have qualifier redundantly.
>>> The callback approach does not have such kind of concern.
>>
>> That might be an idea, but is there any performance disadvantage as
>> discussed in [1]?; it looks like that that needs to perform another
>> remote query to see if the supplied tuple satisfies the pushed-down
>> quals during EPQ testing.
>>
> I expect the callback of ForeignRecheck runs ExecQual() towards
> the qualifier expression pushed-down but saved on the private data
> of ForeignScanState. It does not need to kick another remote query
> (unless FDW driver is not designed), so performance disadvantage is
> none or quite limited.

The advantages look not clear to me.

I think the callback approach would be a good idea if FDWs were able to
do the recheck more efficiently in their own ways than the core, for
example.

Best regards,
Etsuro Fujita