2012/8/27 Shigeru HANADA <shigeru.han...@gmail.com>: > Kaigai-san, > > On Thu, Aug 23, 2012 at 2:10 PM, Kohei KaiGai <kai...@kaigai.gr.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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
