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