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