Re: Cursors performance (was: Re: [PERFORM] Terrible performance

From: Kris Jurka <books(at)ejurka(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 (was: Re: [PERFORM] Terrible performance
Date: 2004-07-09 20:44:32
Message-ID: Pine.BSO.4.56.0407091542140.17911@leary.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc pgsql-performance

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

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Bill Chandler 2004-07-09 21:03:48 Re: Cursors performance (was: Re: [PERFORM] Terrible performance after deleting/recreating indexes)
Previous Message Dave Cramer 2004-07-09 20:39:01 Re: Cursors performance (was: Re: [PERFORM] Terrible

Browse pgsql-performance by date

  From Date Subject
Next Message Bill Chandler 2004-07-09 21:03:48 Re: Cursors performance (was: Re: [PERFORM] Terrible performance after deleting/recreating indexes)
Previous Message Dave Cramer 2004-07-09 20:39:01 Re: Cursors performance (was: Re: [PERFORM] Terrible