Re: [HACKERS] Solution for LIMIT cost estimation

At 11:41 AM 2/14/00 +0200, Hannu Krosing wrote:

>It's utility was much debated befor it was included in Postgres, 
>the main argument for inclusion being "mySQL has it and it's useful 
>for fast-start queries", the main argument against being "it's not SQL,
>people won't understand it a and will start to misuse it".

Well, it appears people have started to misuse it! :)

Oracle has recently (8i or 8.1.6 if you prefer) offered something similar,
but it gives weird results depending on whether or not you have an index
on the column.  There's a kludgey workaround, which I forget since I don't
use Oracle, only laugh maniacly when it fails to install on a linux box
with less than 256MB combined RAM and swap space (i.e. virtual memory).

>Maybe we should still discourage the use of LIMIT, and rather introduce 
>another "mode" for optimiser, activated by SET FastStart TO 'ON'.
>Then queries with limit could be rewritten into
>SET FastStart to 'ON';
>DECLARE
>MOVE
>FETCH
>CLOSE
>SET FastStart to PREVIOUS_VALUE;
>
>also maybe we will need PUSH/POP for set commands ?

Well...personally I don't see LIMIT as being particularly harmful,
and it is a convenience.  Remember, for the web space you're speaking
of keeping overhead low is a real concern, and requiring a series
of queries where currently only one needed will probably go over like
a lead ballon.

If the documentation actually pointed out that LIMIT in the absence
of an ORDER BY clause probably doesn't do what you want, fewer folks
might expect it to work any differently than it does.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.