Re: Optimization for updating foreign tables in Postgres FDW
От | Noah Misch |
---|---|
Тема | Re: Optimization for updating foreign tables in Postgres FDW |
Дата | |
Msg-id | 20160419031651.GC1984253@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Optimization for updating foreign tables in Postgres FDW (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Optimization for updating foreign tables in Postgres FDW
|
Список | 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 по дате отправления: