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.2040...@lab.ntt.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers