|
Home > Archive > PostgeSQL ODBC > February 2006 > Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through
|
|
| Arnaud Lesauvage 2006-02-10, 9:23 am |
| Marc Herbert a écrit :
> Same thing if you force TCP to send ACKs more frequently using
> TcpAckFrequency: then you'll get some TCP_NO_DELAY effect as a
> bonus. Once you decided to send an ACK, then better send the staging
> data in the same packet!
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. Or am I still misunderstanding something ?
Regards
--
Arnaud
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Tom Lane 2006-02-10, 11:23 am |
| Arnaud Lesauvage <thewild@freesurf.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/pgsq...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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Arnaud Lesauvage 2006-02-10, 11:23 am |
| Tom Lane a écrit :
> 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 ...
Yes.
I am trying to figure out what the difference is between an ODBC
call and a "direct" call, from another application...
The issue might be at a higher level, but I have no clue right now...
Regards
--
Arnaud
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
|
|
|
|
|