> Magnus Hagander a écrit :
> > Since it works with different speeds in different clients, it
> > *probably* isn't on the server side. I'm far from sure on
> that though,
> > there may be other paramters that are implicitly changed
> when ODBC is used.
>
> Yes, that was my first impression also. But the fact that the
> server waits for an ACK from the client before it goes on
> sending packet is quite strange, isn't it ?
Yes. Most definitly.
> > It's interesting to note that your problem is with a single
> large field.
> > If you query for approximatly the same amount of data *but
> in several
> > small fields*, do you get the same behaviour? Or does it
> happen only
> > with large fields?
>
> I have splitted the data into 4 fields.
> The largest field was ~23.000 characters long, so I made 4
> fields containing. The first one contains the first 6000, the
> second one from 6001 to 12000, etc...
> The query took about half the time to run !
Interesting. Did it make any difference to the timings in psql and/or pgadmin?
> > We enable TCP_NODELAY on both server and client, when
> available. And
> > it is available - I've double-checked and that code is
> indeed compiled
> > into both libpq and the server on 8.1 at least.
>
> I run 8.1.2, so I assume that it is enabled on my workstation
> and on the server.
Yup.
> > But I don't see how this can make a difference between pgadmin and
> > odbc and psql, since they all use the same code!
>
> Yes, I really don't understand either !
> But even though all use libpq.dll, they might not handle the
> data the same way. Mayboe ODBC needs to check for data type,
> field length, etc... and the other frontends do not need this
> kind of information ?
Hm. That's an interesting observation. When you do a query with ODBC, does it do any "extra queries" automatically on
thesystem tables? Enable statement logging on the server and see if something weird shows up.
//Magnus
