Re: CURSOR slowes down a WHERE clause 100 times? - Mailing list pgsql-performance

From Niccolo Rigacci
Subject Re: CURSOR slowes down a WHERE clause 100 times?
Date
Msg-id 20050707100658.GA19237@rigacci.org
Whole thread Raw
In response to Re: CURSOR slowes down a WHERE clause 100 times?  (Richard Huxton <dev@archonet.com>)
List 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 by date:

Previous
From: Richard Huxton
Date:
Subject: Re: CURSOR slowes down a WHERE clause 100 times?
Next
From: Bendik Rognlien Johansen
Date:
Subject: How to speed up delete