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 working in
this manner)
Now, change the FETCH_COUNT to 10, then 50, then 100 - your query
execution time should be better (at least I hope so :))
And if it's better - you simply need to modify your FETCH clause with
adapted "FORWARD #" value (the best example is psql source code
itself, you may find ExecQueryUsingCursor function implementation
(file common.c))...
Rgds,
-Dimitri
On 6/22/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
Hello Dimitri,
>but did you try to execute your query directly from 'psql' ?...
munnin=>\timing
munnin=>select * from "tblItem";
<data snipped>
(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 PostgreSQL
>the SELECT query become very traffic hungry if you are using CURSOR.
>Program 'psql' is implemented to not use CURSOR by default, so it'll
>be easy to check if you're meeting this issue or not just by executing
>your query remotely from 'psql'...
Yes, see also my other post.
Unfortunatelly this means that using my program to connect via DSL to the
Postgres database is not possible.
Rainer
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
