Hello Dimitri,
>Rainer, seeking psqlODBC code source it seems to work in similar way
>and have an option "SQL_ROWSET_SIZE" to execute FETCH query in the
>same way as "FETCH_COUNT" in psql. Try to set it to 100 and let's see
>if it'll be better...
But that is only for bulk fetching with SQLExtende
Hello Joshua,
>That opens up some questions. What ODBC driver are you using (with exact
>version please).
psqlODBC 8.2.4.2 (build locally).
I have restored the 8.2.4.0 from the official msi installer, but the results
are the same.
Rainer
---(end of broadcast)--
Hello Dimitri,
>Hope it's more clear now and at least there is a choice :))
>As well, if your query result will be 500 (for ex.) I think the
>difference will be less important between non-CURSOR and "FETCH 500"
>execution...
The problem is that I am using ODBC and not libpq directly.
I will have
Hello Dimitri,
>Let's stay optimist - at least now you know the main source of your problem!
>:))
>
>Let's see now with CURSOR...
>
>Firstly try this:
>munnin=>\timing
>munnin=>\set FETCH_COUNT 1;
>munnin=>select * from "tblItem";
>
>what's the time you see here? (I think your application is work
Hello Dimitri,
>Rainer, but did you try initial query with FETCH_COUNT equal to 100?...
Yes I tried it with different values and it's like you suspected:
FETCH_COUNT 1 Time: 8642,000 ms
FETCH_COUNT 5 Time: 2360,000 ms
FETCH_COUNT 10 Time: 1563,000 ms
FETCH_COUNT 25 Time: 1329,000 ms
FETCH_COUN
Hello Tom,
>This previous post says that someone else solved an ODBC
>performance problem with UseDeclareFetch=1:
I thought about that too, but enabling UseDeclareFetch will slow down the
query: it takes 30 seconds instead of 8.
>It's not immediately clear why pgAdmin would have the same issue,
Hello Dimitri,
>but did you try to execute your query directly from 'psql' ?...
munnin=>\timing
munnin=>select * from "tblItem";
(50 rows)
Time: 391,000 ms
>Why I'm asking: seems to me your case is probably just network latency
>dependent, and what I noticed during last benchmarks with PostgreS
I wrote:
>Hello Harald,
>
>>I do not have a solution, but I can confirm the problem :)
>
>At least that rules out any misconfiguration issues :-(
I did a quick test with my application and enabled the ODBC logging.
Fetching the 50 rows takes 12 seconds (without logging 8 seconds) and
examining t
Hello Harald,
>I do not have a solution, but I can confirm the problem :)
At least that rules out any misconfiguration issues :-(
>I did not find a solution so far; and for bulk data transfers I now
>programmed a workaround.
But that is surely based on some component installed on the server, is
Hello Tom,
>I seem to recall that we've seen similar reports before, always
>involving Windows :-(. Check whether you have any nonstandard
>components hooking into the network stack on that machine.
I just repeated the test by booting into "Safe Mode with Network Support", but
the results are th
Hello all,
one of my customers installed Postgres on a public server to access the data
from several places. The problem is that it takes _ages_ to transfer data from
the database to the client app. At first I suspected a problem with the ODBC
driver and my application, but using pgAdminIII 1.6.3
11 matches
Mail list logo
