Re: CURSOR slowes down a WHERE clause 100 times?

Поиск
Список
Период
Сортировка
От Niccolo Rigacci
Тема Re: CURSOR slowes down a WHERE clause 100 times?
Дата
Msg-id 20050707100658.GA19237@rigacci.org
обсуждение исходный текст
Ответ на Re: CURSOR slowes down a WHERE clause 100 times?  (Richard Huxton <dev@archonet.com>)
Список pgsql-performance
On Thu, Jul 07, 2005 at 10:14:50AM +0100, Richard Huxton wrote:
> >By trial and error I discovered that adding an "ORDER BY
> >toponimo" clause to the SELECT, boosts the CURSOR performances
> >so that they are now equiparable to the SELECT alone.

> I think you're misunderstanding exactly what's happening here. If you
> ask for a cursor, PG assumes you aren't going to want all the results
> (or at least not straight away). After all, most people use them to work
> through results in comparatively small chunks, perhaps only ever
> fetching 1% of the total results.

This make finally sense!

> In your case, since you're immediately issuing FETCH ALL,
> you're not really using the cursor at all, but PG doesn't know
> that.

In fact, fetching only the first rows from the cursor, is rather
quick! This demonstrates that the PG planner is smart.

Not so smart are the MapServer and QGIS query builders, which use
a CURSOR to FETCH ALL.

I will investigate in this direction now.

Thank you very much, your help was excellent!

--
Niccolo Rigacci
Firenze - Italy

War against Iraq? Not in my name!

В списке pgsql-performance по дате отправления:

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: CURSOR slowes down a WHERE clause 100 times?
Следующее
От: Bendik Rognlien Johansen
Дата:
Сообщение: How to speed up delete