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=>\set FETCH_COUNT 1;
munnin=>select * from "tblItem";
what's the time you see here? (I think your application is working in
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
On 6/22/07, Rainer Bauer <usenet(at)munnin(dot)com> wrote:
> Hello Dimitri,
> >but did you try to execute your query directly from 'psql' ?...
> 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.
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
In response to
pgsql-performance by date
|Next:||From: Scott Marlowe||Date: 2007-06-21 23:10:32|
|Subject: Re: Performance query about large tables, lots of concurrent
|Previous:||From: Scott Marlowe||Date: 2007-06-21 22:29:15|
|Subject: Re: Hardware suggestions|