Etsuro Fujita <fujita.etsuro@lab.ntt.co.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.
regards, tom lane
