From: "Peter T. Breuer" <ptb@inv.it.uc3m.es>
Message-Id: <200705251506.l4PF6AW08031@inv.it.uc3m.es>
Subject: Re: general PG network slowness (possible cure) (repost)
In-Reply-To: <20070525141013.GC4239@alvh.no-ip.org> from "Alvaro Herrera" at
	"May 25, 2007 10:10:13 am"
To: "Alvaro Herrera" <alvherre@commandprompt.com>
Date: Fri, 25 May 2007 17:06:10 +0200 (MET DST)
CC: "Peter T. Breuer" <ptb@inv.it.uc3m.es>,
	"Richard Huxton" <dev@archonet.com>, pgsql-performance@postgresql.org
Reply-To: ptb@inv.it.uc3m.es
Reply-By: Sat, 1 Apr 2006 14:21:08 -0700

"Also sprach Alvaro Herrera:"
> > I really think it would be worthwhile getting some developer to tell me
> > where the network send is done in PG.
> 
> See src/backend/libpq/pqcomm.c (particularly internal_flush()).

Yes. Thanks. That looks like it. It calls secure_write continually
until the buffer is empty.

Secure_write is located ibe-secure.c, but I'm not using ssl, so the 
call reduces to just

    n = send(port->sock, ptr, len, 0);

And definitely all those could be grouped if there are several to do.
But under normal circumstances the send will be pushing against a
lttle resistance (the copy to the driver/protocol stack buffer is faster
than the physical network send, by a ratio of GB/s to MB/s, or 1000 to
1), and thus all these sends will probably complete as a single unit
once they have been started.

It's worth a try.  I thought first this may be too low level, but it
looks as though internal_flush is only triggered when some other buffer
is full, or deliberately, so it may be useful to block until it fires.

I'll try it.


Peter