Re: PostgreSQL pre-fork speedup

James Robinson <jlrobins@socialserve.com> writes:
> Quick overview of the code for differences in TCP-on-the-frontend code 
> is a call to setsockopt(..., TCP_NODELAY, ...) if the connection to the 
> frontend is a TCP socket. Could this be producing pseudo-fragmentation, 
> resulting in over-the-top context switches?

Could be.  Although libpq and the backend both set that option, they are
both careful not to present data to the kernel at all until they have a
full buffer or need a response from the far end.  pgpool seems way too
enthusiatic about flushing after each logical message --- or even part
of a logical message in some places.  I'd expect this is presenting
nontrivial extra overhead in the Unix-socket case too (at the minimum,
more kernel calls than necessary).  But it'd really hurt in TCP if we're
sending packets with just a few bytes ...

Possibly pgpool could be taught to flush only after "significant"
messages that indicate query completion or a request for response.  At
the very least I'd get rid of the flushes associated with AsciiRow and
BinaryRow messages.  Those would be a lot of overhead during a large
select retrieval.

			regards, tom lane