Re: Cursors performance (was: Re: [PERFORM] Terrible performance - Mailing list pgsql-jdbc

From Kris Jurka
Subject Re: Cursors performance (was: Re: [PERFORM] Terrible performance
Date
Msg-id Pine.BSO.4.56.0407091542140.17911@leary.csoft.net
Whole thread Raw
In response to Cursors performance (was: Re: [PERFORM] Terrible performance after deleting/recreating indexes)  (Bill Chandler <billybobc1210@yahoo.com>)
List pgsql-jdbc

On Fri, 9 Jul 2004, 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
>

If the top level node of your execution plan is a sort step, it should
take essentially no time to retrieve additional rows after the first
fetch.  The sort step is materializes the results so that future fetches
simply need to spit this data back to the client.

I would agree with Dave's suggestion to use log_duration and compare the
values for the first and subsequent fetches.

Kris Jurka


pgsql-jdbc by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Cursors performance (was: Re: [PERFORM] Terrible
Next
From: Bill Chandler
Date:
Subject: Re: Cursors performance (was: Re: [PERFORM] Terrible performance after deleting/recreating indexes)