Re: FDW for PostgreSQL
Shigeru Hanada <shigeru.hanada@gmail.com>
From: Shigeru Hanada <shigeru.hanada@gmail.com>
To: Albe Laurenz <laurenz.albe@wien.gv.at>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Kohei KaiGai <kaigai@kaigai.gr.jp>, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2013-02-14T10:11:01Z
Lists: pgsql-hackers
On Thu, Feb 14, 2013 at 6:45 PM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote: > Shigeru Hanada wrote: >> Tom Lane wrote: >>> It ought to be pulling the rows back a few at a time, and >>> that's not going to work well if multiple scans are sharing the same >>> connection. (We might be able to dodge that by declaring a cursor >>> for each scan, but I'm not convinced that such a solution will scale up >>> to writable foreign tables, nested queries, subtransactions, etc.) >> >> Indeed the FDW used CURSOR in older versions. Sorry for that I have >> not looked writable foreign table patch closely yet, but it would >> require (may be multiple) remote update query executions during >> scanning? > > It would for example call ExecForeignUpdate after each call to > IterateForeignScan that produces a row that meets the UPDATE > condition. Thanks! It seems that ExecForeignUpdate needs another connection for update query, or we need to retrieve all results at the first Iterate call to prepare for possible subsequent update query. -- Shigeru HANADA