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

Поиск
Список
Период
Сортировка
От Kris Jurka
Тема Re: Cursors performance (was: Re: [PERFORM] Terrible performance
Дата
Msg-id Pine.BSO.4.56.0407091542140.17911@leary.csoft.net
обсуждение исходный текст
Ответ на Cursors performance (was: Re: [PERFORM] Terrible performance after deleting/recreating indexes)  (Bill Chandler <billybobc1210@yahoo.com>)
Список 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 по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: Cursors performance (was: Re: [PERFORM] Terrible
Следующее
От: Bill Chandler
Дата:
Сообщение: Re: Cursors performance (was: Re: [PERFORM] Terrible performance after deleting/recreating indexes)