Skip site navigation (1) Skip section navigation (2)

AW: LIMIT in DECLARE CURSOR: request for comments

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: AW: LIMIT in DECLARE CURSOR: request for comments
Date: 2000-10-30 08:34:03
Message-ID: 11C1E6749A55D411A9670001FA6879633680D4@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> After thinking some more about yesterday's discussions, I propose that
> we adopt the following planning behavior for cursors:
> 
> 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
> basis of 10%-or-so fetch (I'd consider anywhere from 5% to 25% to be
> just as reasonable, if people want to argue about the exact number;
> perhaps a SET variable is in order?).  10% seems to be a reasonable
> compromise between delivering tuples promptly and not choosing a plan
> that will take forever if the user fetches the whole result.

Imho that was a wrong assumption in the first place. The default assumption 
imho needs to be 100 %. Especially if you fixed the limit clause enabling people
to optimize the few rows fetched case.

> 3. If DECLARE CURSOR contains "LIMIT ALL", plan on the assumption that
> all tuples will be fetched, ie, select lowest-total-cost plan.
> 
> (Note: LIMIT ALL has been in the grammar right along, but up to now
> it has been entirely equivalent to leaving out the LIMIT clause.  This
> proposal essentially suggests allowing it to act as a planner 
> hint that
> the user really does intend to fetch all the tuples.)
> 
> Comments?

Imho an explicit statement to switch optimizer mode from all rows to first rows
would be a lot easier to understand and is what other DB vendors do.

Andreas

Responses

pgsql-hackers by date

Next:From: Peter MountDate: 2000-10-30 09:42:20
Subject: Current CVS broken?
Previous:From: Adriaan JoubertDate: 2000-10-30 08:32:53
Subject: Re: BIT/BIT VARYING status

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group