> 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 the system tables? Enable statement logging on the server and see if something weird shows up.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

>> 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?

No, not at all. Actually, it even runs a tiny bit slower in
pgAdmin (2.05 sec vs 1.95 for the "one large field" version).


>> 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 the system tables? Enable statement logging on the server and see if something weird shows up.

No, no query on the system tables.
I am not very familiar with the log though, maybe Ludek could tell
us more about that ?

Regards
--
Arnaud


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

> >>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 the system tables? Enable
> >statement logging on the server and see if something weird shows up.
>
> No, no query on the system tables.
> I am not very familiar with the log though, maybe Ludek could tell
> us more about that ?

If I remember it right we measure the time problem in LIBPQ_send_query
function in connection.c (I'm not sure with filename).
Magnus, could you take a look at the code? Maybe you find the problem.
I'm sorry I have no time for it today.
BTW we change the code between 08.01.0102 and 08.01.0200 from PQexec
to PQsendquery and PQgetresult (I write this from my head so it could
be little different names). But I think Arnaud has problem even with
08.01.0102.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly