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-27 07:15:12 |
Message-ID: | 55B5DA80.3050902@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
KaiGai-san,
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.
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/5590ED5C.2040200@lab.ntt.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Mamin | 2015-07-27 07:52:00 | Re: pg_dump -Fd and compression level |
Previous Message | Kyotaro HORIGUCHI | 2015-07-27 07:04:38 | Re: multivariate statistics / patch v7 |