Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through

Arnaud Lesauvage <thewild(at)freesurf(dot)fr> writes:
> OK, but Magnus is affirmative that TCP_NO_DELAY is enabled on both
> the client and the server.
> So sending ACKs more frequently should not change the behaviour of
> the Nagle algorithm.

Yeah. The speculations quoted in
http://archives.postgresql.org/pgsql-odbc/2006-02/msg00046.php
as to the server behavior were completely wrong: we do use NODELAY
and we don't have any weird zero-copy algorithm. However, it is
true that we push out data in 8K bufferloads, which doesn't match
well to typical TCP MTU sizes. I've occasionally wondered whether
we should not try to make the bufferload a multiple of the MTU
size when using a TCP connection, just so that no "short" packets
get sent unnecessarily. (For a known MTU length, it'd be trivial
to change the hard-wired buffer size on the server side just to
experiment and see if there's any speedup.)

None of this explains why odbc is slow when psql isn't, though,
especially not if you are using one of the recent odbc releases
that relies on libpq. The wire-level behavior certainly ought
to be the same for anything using libpq ...

regards, tom lane