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  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: parallel query vs extensions
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Optimization for updating foreign tables in Postgres FDW