Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through
От
Tom Lane
Тема
Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through
Дата
Msg-id
19555.1139585881@sss.pgh.pa.us
Ответ на
Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through (Arnaud Lesauvage)
Список
Дерево обсуждения
TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through ODBC) Marc Herbert <Marc.Herbert@continuent.com>
Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through Arnaud Lesauvage <thewild@freesurf.fr>
Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through Arnaud Lesauvage <thewild@freesurf.fr>
Arnaud Lesauvage 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
В списке pgsql-odbc по дате отправления
От: Arnaud Lesauvage
Дата: