Re: Cursors performance

From: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>
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-10 03:06:20
Message-ID: 40EF5D2C.5080506@coretech.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc pgsql-performance

Might be worth doing a little test:

i) modify your code to fetch 1 row at a time
ii) set log_duration=true in your postgresql.conf (as the other posters
have suggested)

Then compare with running the query in psql.

regards

Mark

Bill Chandler wrote:

>Thanks to all who have responded. I now think my
>problem is not related to deleting/recreating indexes.
>Somehow it is related to JDBC cursors. It appears
>that what is happening is that since I'm using
>a fetch size of 5000, the command:
>
>FETCH FORWARD 5000 FROM JDBC_CURS_1
>
>is being repeatedly sent to the server as I process
>the result set from my query. Each time this command
>is sent it it takes about 5 minutes to return which is
>about the amount of time the whole query took to
>complete before the performance degredation. So in
>other words it looks as if the full select is being
>rerun on each fetch.
>
>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.
>
>Could I have inadvertently changed a parameter
>somewhere that would cause this behavior?
>
>thanks,
>
>Bill
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend
>
>

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Greg Markham 2004-07-10 16:01:40 Timestamp Question
Previous Message Kris Jurka 2004-07-09 23:58:40 Re: patch: complain obviously about unknown transaction states

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-07-10 03:10:04 Re: Forcing HashAggregation prior to index scan?
Previous Message Tom Lane 2004-07-10 02:52:04 Re: inserting into brand new database faster than old database