Re: [Bug] Inconsistent result for inheritance and FOR UPDATE.

(2014/12/16 2:59), Tom Lane wrote:
> Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> writes:
>> (2014/12/13 1:17), Tom Lane wrote:
>>> We should
>>> probably also think about allowing FDWs to change these settings if
>>> they want to.
>
>> This is not clear to me. Maybe I'm missing something, but I think that
>> the FDW only needs to look at the original locking strength in
>> GetForeignPlan(). Please explain that in a little more detail.
>
> Well, the point is that for postgres_fdw, we could consider using the
> same locked-row-identification methods as for local tables, ie CTID.
> Now admittedly this might be the only such case, but I'm not entirely
> convinced of that --- you could imagine using FDWs for many of the same
> use-cases that KaiGai-san has been proposing custom scans for, and
> in some of those cases CTIDs would be useful for row IDs.
>
> We'd originally dismissed this on the argument that ROWMARK_REFERENCE
> is a cheaper implementation than CTID-based implementations for any
> FDW (since it avoids the possible need to fetch a remote row twice).
> I'm not sure I still believe that though. Fetching all columns of all
> retrieved rows in order to avoid what might be zero or a small number of
> re-fetches is not obviously a win, especially not for FDWs that
> represent not-actually-remote resources.
>
> So as long as we're revisiting this area, it might be worth thinking
> about letting an FDW have some say in which ROWMARK method is selected
> for its tables.

Understood. So, to what extext should we consider such things in the
FDW improvement? We've already started an independent infrastructure
for such things, ie, custom scans, IIUC.

Thank you for the explanation!

Best regards,
Etsuro Fujita