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)
Список
Дерево обсуждения
CURSOR slowes down a WHERE clause 100 times? Niccolo Rigacci <niccolo@rigacci.org>
Re: CURSOR slowes down a WHERE clause 100 times? Niccolo Rigacci <niccolo@rigacci.org>
Re: CURSOR slowes down a WHERE clause 100 times? Richard Huxton <dev@archonet.com>
Re: CURSOR slowes down a WHERE clause 100 times? Niccolo Rigacci <niccolo@rigacci.org>
Re: CURSOR slowes down a WHERE clause 100 times? John A Meinel <john@arbash-meinel.com>
Re: CURSOR slowes down a WHERE clause 100 times? Niccolo Rigacci <niccolo@rigacci.org>
Re: CURSOR slowes down a WHERE clause 100 times? Tom Lane <tgl@sss.pgh.pa.us>
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 по дате отправления