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
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 |
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 |