|
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
|
|
| Philippe Lang 2006-02-13, 7:23 am |
| Hi,
Why don't you use tcpdump, or another sniffer, in order to check that, and
post the result here?
-----Message d'origine-----
De : pgsql-odbc-owner@postgresql.org
[mailto:pgsql-odbc-owner@postgresql.org] De la part de Arnaud Lesauvage
Envoyé : vendredi, 10. février 2006 17:01
À : Tom Lane
Cc : pgsql-odbc@postgresql.org
Objet : Re: [ODBC] TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through
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
| |
| Arnaud Lesauvage 2006-02-13, 7:23 am |
| Philippe Lang a écrit :
> Why don't you use tcpdump, or another sniffer, in order to check that, and post the result here?
Hi,
Sure !
Here are the two dumps.
http://tehwild.free.fr/divers/dumps.zip
One is a TCP dump of the query through pgAdmin, the other one
through psqlODBC.
The first obvious difference is that the window size is not the
same, but I don't know how to interpret that.
Regards
--
Arnaud
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Marc Herbert 2006-02-20, 7:23 am |
| Arnaud Lesauvage <thewild@freesurf.fr> writes:
>
> Sure !
> Here are the two dumps.
> http://tehwild.free.fr/divers/dumps.zip
> One is a TCP dump of the query through pgAdmin, the other one
> through psqlODBC.
> The first obvious difference is that the window size is not the same,
> but I don't know how to interpret that.
The best free tools I know to analyze such issues is tcptrace + xplot
<http://www.tcptrace.org/>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
|
| You may try "ethereal" which can give you more details than the TCP
dumps with a structured view of packets and protocol layers.
Olivier.
Marc Herbert wrote:
>Arnaud Lesauvage <thewild@freesurf.fr> writes:
>
>
>
>The best free tools I know to analyze such issues is tcptrace + xplot
>
><http://www.tcptrace.org/>
>
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
>
>
>
| |
| Arnaud Lesauvage 2006-02-20, 9:23 am |
| O B a écrit :
> You may try "ethereal" which can give you more details than the TCP
> dumps with a structured view of packets and protocol layers.
The included dumps *are* ethereal dumps, actually.
There must be a reason why psqlODBC sets a different RWIN than the
other frontends (psql and pgAdmin), but I don't know which one.
Regards
--
Arnaud
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Marc Herbert 2006-02-20, 9:23 am |
| O B <ob@kselnet.com> writes:
> You may try "ethereal" which can give you more details than the TCP
> dumps with a structured view of packets and protocol layers.
ethereal is a great general-purpose tool but is not good at analyzing
TCP performance issues, because you only get numbers. With
tcptrace/xplot you get graphical timelines of sequence numbers and of
window sizes; I don't think ethereal can't match that. It's the same
difference between an excel spreadsheet and the corresponding graph.
Of course you have to be sure that your performance issue is somewhat
related to TCP parameters, else there is no need to go into tcptrace.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
|
|
|
|
|