From: | Roman Neuhauser <neuhauser(at)sigpipe(dot)cz> |
---|---|
To: | "biuro(at)globeinphotos(dot)com" <biuro(at)globeinphotos(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Why my cursor construction is so slow? |
Date: | 2006-07-07 11:30:35 |
Message-ID: | 20060707113035.GA2400@dagan.sigpipe.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
# kleptog(at)svana(dot)org / 2006-06-22 09:19:44 +0200:
> On Tue, Jun 20, 2006 at 02:06:19AM -0700, biuro(at)globeinphotos(dot)com wrote:
> > Such construction is very slow but when I modify SQL to:
> > OPEN cursor1 FOR SELECT * FROM alias WHERE mask>=alias_out
> > ORDER BY mask LIMIT 100;
> >
> > it works very fast. It is strange for me becuase I've understood so far
> > that when cursor is open select is executed but Postgres does not
> > select all rows - only cursor is positioned on first row, when you
> > execute fetch next row is read. But this example shows something
> > different.
>
> PostgreSQL tries to optimise for overall query time. Without the limit
> it tries to find a plan that will return the whole set as quick as
> possible.
That looks like the wrong approach for a cursor.
> With the LIMIT it might take a different approach, which
> might be worse if you read the whole lot, but better for a limited set.
> A fast-start plan so to speak.
That looks like a better approach for a cursor.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
From | Date | Subject | |
---|---|---|---|
Next Message | Kenneth Downs | 2006-07-07 11:44:02 | Re: Version/Change Management of functions? |
Previous Message | badlydrawnbhoy | 2006-07-07 11:29:51 | How to optimize query that concatenates strings? |