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

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: We need to support ForeignRecheck for late row locking, don't we?
Date: 2015-07-30 10:20:43
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-07-30 10:44:37 Re: pg_dump quietly ignore missing tables - is it bug?
Previous Message Etsuro Fujita 2015-07-30 10:15:59 Re: Foreign join pushdown vs EvalPlanQual