| From: | Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com> |
|---|---|
| To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FDW for PostgreSQL |
| Date: | 2013-02-14 10:11:01 |
| Message-ID: | CAEZqfEeh7LjZKAG=JCv4dSDdMBm8xh_66OV=Em9+gTJbPXHLxA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 14, 2013 at 6:45 PM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manlio Perillo | 2013-02-14 12:01:36 | libpq test suite |
| Previous Message | Albe Laurenz | 2013-02-14 09:45:04 | Re: FDW for PostgreSQL |