Re: Optimization for updating foreign tables in Postgres FDW - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Optimization for updating foreign tables in Postgres FDW
Date
Msg-id CAB7nPqRNzrfc3ua=BhUvmEmr2mXRGn80aZ0MUAav4SsNq+xO+w@mail.gmail.com
Whole thread Raw
In response to Re: Optimization for updating foreign tables in Postgres FDW  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Optimization for updating foreign tables in Postgres FDW  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Fri, Apr 15, 2016 at 9:46 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Fri, Apr 15, 2016 at 8:25 PM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:
>> How about doing something similar for PQprepare/PQexecPrepared in
>> postgresExecForeignInsert, postgresExecForeignUpdate, and
>> postgresExecForeignDelete?
>
> Yes, I hesitated to touch those, but they are good candidates for this
> new interface, and actually it has proved not to be complicated to
> plug in the new routines in those code paths.
>
>> Also, how about doing that for PQexec in connection.c?
>
> Here I disagree, this is not adapted. All the PQexec calls are part of
> callbacks that are triggered on failures, and we rely on such a
> callback when issuing PQcancel. do_sql_command runs commands that take
> a short amount of time, so I think as well that it is fine as-is with
> PQexec.

Here is a new version. I just recalled that I forgot a PQclear() call
to clean up results.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Is a syscache tuple more like an on-disk tuple or a freshly made one?
Next
From: Stephen Frost
Date:
Subject: Re: [COMMITTERS] pgsql: Add new catalog called pg_init_privs