From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Bill Chandler <billybobc1210(at)yahoo(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Cursors performance |
Date: | 2004-07-09 21:55:35 |
Message-ID: | 40EF1457.1060002@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc pgsql-performance |
Bill Chandler wrote:
> Now the mystery is why is this happening all of the
> sudden? I have been running w/ fetch size set to 5000
> for the last couple of weeks and it did not appear to
> be doing this (i.e. re-running the entire select
> statement again). Is this what I should expect when
> using cursors? I would have thought that the server
> should "remember" where it left off in the query since
> the last fetch and continue from there.
I'd check heap size, GC activity (-verbose:gc), CPU use, swapping
activity on the *client* side. It may be that your dataset size or
physical memory or something similar has changed sufficiently that GC
resulting from the data in each 5k row batch is killing you.
Can you try a trivial app that runs the same query (with same fetchsize,
autocommit, etc) via JDBC and does nothing but steps forward through the
resultset, and see how fast it runs? Perhaps the problem is in your
processing logic.
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2004-07-09 22:34:05 | Re: patch for getXXX methods |
Previous Message | Bill Chandler | 2004-07-09 21:41:26 | Re: Cursors performance (was: Re: [PERFORM] Terrible performance after deleting/recreating indexes) |
From | Date | Subject | |
---|---|---|---|
Next Message | Mischa Sandberg | 2004-07-09 22:23:03 | Re: Inverted-list databases (was: Working on huge RAM based datasets) |
Previous Message | Bill Chandler | 2004-07-09 21:18:01 | Re: Cursors performance (was: Re: [PERFORM] Terrible performance after deleting/recreating indexes) |