Re: [v9.3] writable foreign tables

2012/8/27 Shigeru HANADA <shigeru(dot)hanada(at)gmail(dot)com>:
> Kaigai-san,
>
> On Thu, Aug 23, 2012 at 2:10 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> The patched portion at contrib/file_fdw.c does not make sense
>> actually. It just prints messages for each invocation.
>> It is just a proof-of-concept to show possibility of implementation
>> based on real RDBMS.
>
> Attached is a tar ball of pgsql_fdw. It's WIP and contains no
> document, but it would be enough for your PoC purpose. Usage and
> features are same as the last version posted for 9.2 cycle.
> # I'll post finished patch in the CF-Sep.
>
Thanks, it is helpful to work on.

> Here are random comments for your PoC patch:
>
> + As Robert says, using CTID as virtual tuple identifier doesn't seem
> nice when considering various FDWs for NoSQL or RDBMS. Having abstract
> layer between FDWs and tuple sounds better, but implementing it by each
> FDW seems useless effort. Do yo have any idea of generic mechanism for
> tuple mapping?
>
As I wrote in the previous message, isn't it a reasonable idea to move
a private datum (instead of alternate key) on the "ctid" field which has
been internally represented as a pointer to indicate ItemPointerData?

> + Do you have any plan about deparsing local qualifiers into remote
> query to avoid repeated query submission? This would improve
> performance of big UPDATE, but its use case might be limited to
> statements which consist of one foreign table. For this case, we can
> consider pass-through mode as second way.
>
I think, FDW should run UPDATE or DELETE statement at the scan
stage on remote-side, then return a pseudo result to scanner, in case
of the statement is "enough simple", like no qualifier, no returning, etc...
The callback on ExecUpdate/ExecDelete will perform just a stub; that
does not actually work except for increment of affected rows.

> + I have not read your patch closely yet, but I wonder how we can know
> which column is actually updated. If we have only updated image of
> tuple, we have to update all remote columns by "new" values?
>
It seems to me TargetEntry of the parse tree can inform us which column
should be modified on UPDATE or INSERT. If it has just a Var element
that reference original table as-is, it means here is no change.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>