Re: Optimization for updating foreign tables in Postgres FDW

From: Noah Misch <noah(at)leadboat(dot)com>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimization for updating foreign tables in Postgres FDW
Date: 2016-04-08 04:42:05
Message-ID: 20160408044205.GA1709423@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 05, 2016 at 03:22:03PM +0900, Etsuro Fujita wrote:
> On 2016/04/04 20:35, Michael Paquier wrote:
> >On Mon, Apr 4, 2016 at 7:49 PM, Etsuro Fujita
> ><fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> >>Here is a patch to fix this issue. As proposed by Michael, I modified
> >>execute_dml_stmt so that it uses PQsendQueryParams, not PQexecParams. Any
> >>comments are welcome.
>
> >+ * This is based on pqSocketCheck.
> >+ */
> >+ bool
> >+ CheckSocket(PGconn *conn)
> >+ {
> >+ int ret;
> >+
> >+ Assert(conn != NULL);
> >Instead of copying again pqSocketQuery, which is as well copied in
> >libpqwalreceiver.c, wouldn't it be better to use WaitLatchOrSocket
> >with the socket returned by PQsocket?
>
> Will check. Thanks for the comment!

What do you think? This open item's seven-day deadline has passed. It would
help keep things moving to know whether you consider your latest patch optimal
or whether you wish to change it the way Michael described.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-04-08 05:22:19 Re: Choosing parallel_degree
Previous Message Fujii Masao 2016-04-08 04:26:01 Re: Support for N synchronous standby servers - take 2