Re: CURSOR slowes down a WHERE clause 100 times?

From: Niccolo Rigacci <niccolo(at)rigacci(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: CURSOR slowes down a WHERE clause 100 times?
Date: 2005-07-07 10:06:58
Message-ID: 20050707100658.GA19237@rigacci.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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!

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Bendik Rognlien Johansen 2005-07-07 11:16:30 How to speed up delete
Previous Message Richard Huxton 2005-07-07 09:14:50 Re: CURSOR slowes down a WHERE clause 100 times?