Re: [HACKERS] PATCH: Batch/pipelining support for libpq - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] PATCH: Batch/pipelining support for libpq
Date
Msg-id 20170622010721.nbltldlqkkwo6z4j@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] PATCH: Batch/pipelining support for libpq  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] PATCH: Batch/pipelining support for libpq  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] PATCH: Batch/pipelining support for libpq  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2017-06-22 09:03:05 +0800, Craig Ringer wrote:
> On 22 June 2017 at 08:29, Andres Freund <andres@anarazel.de> wrote:
> 
> > I.e. we're doing tiny write send() syscalls (they should be coalesced)
> 
> That's likely worth doing, but can probably wait for a separate patch.

I don't think so, we should get this right, it could have API influence.


> The kernel will usually do some packet aggregation unless we use
> TCP_NODELAY (which we don't and shouldn't), and the syscall overhead
> is IMO not worth worrying about just yet.

1)                /*                 * Select socket options: no delay of outgoing data for                 * TCP
sockets,nonblock mode, close-on-exec. Fail if any                 * of this fails.                 */                if
(!IS_AF_UNIX(addr_cur->ai_family))               {                    if (!connectNoDelay(conn))                    {
                    pqDropConnection(conn, true);                        conn->addr_cur = addr_cur->ai_next;
           continue;                    }                }
 

2) Even if nodelay weren't set, this can still lead to smaller packets  being sent, because you start sending normal
sizedtcp packets,  rather than jumbo ones, even if configured (pretty common these  days).
 

3) Syscall overhead is actually quite significant.

- Andres



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] PATCH: Batch/pipelining support for libpq
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] An attempt to reduce WALWriteLock contention