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

From Noah Misch
Subject Re: Optimization for updating foreign tables in Postgres FDW
Date
Msg-id 20160419031651.GC1984253@tornado.leadboat.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  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Sat, Apr 16, 2016 at 08:59:40AM +0900, Michael Paquier wrote:
> 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.

Robert, the deadline to fix this open item expired eleven days ago.  The
thread had been seeing regular activity, but it has now been quiet for three
days.  Do you have an updated plan for fixing this open item?



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: parallel query vs extensions
Next
From: Michael Paquier
Date:
Subject: Re: Optimization for updating foreign tables in Postgres FDW