James Robinson <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
