Re: [SQL] trivial problem

FAQ says:

See the <I>fetch</I> manual page, or use SELECT ... LIMIT....<P>

This only prevents all row results from being transferred to the client.
The entire query must be evaluated, even if you only want just the first
few rows. Consider a query that has an <I>order by.</I> There is no way
to return any rows until the entire query is evaluated and sorted.<P>

[Charset iso-8859-1 unsupported, filtering to ASCII...]
>
> ----- Original Message -----
> From: <tjk(at)tksoft(dot)com>
> To: Roderick A. Anderson <raanders(at)altoplanos(dot)net>
> Cc: <oleg(at)sai(dot)msu(dot)su>; <pgsql-sql(at)postgreSQL(dot)org>
> Sent: Friday, October 29, 1999 7:12 PM
> Subject: Re: [SQL] trivial problem
>
>
> > If limit didn't mean "get first 50," there would be no time/effort
> > saved by specifying a limit.
> >
> > I.e. when a limit is specified, the backend looks for matches until it
> > finds 50 records, and then stops.
>
> Eh? I think the questioner meant effectively "in a query with LIMIT and
> ORDER BY, which takes precedence?". To which the answer appears to be ORDER
> BY, which surprised me, but is of course very useful.
>
> I.e. all sorting is completed, and then the first fifty records are
> returned.
>
> Does that mean that the seek time for a limited, ordered by query is the
> same as that for an unlimited query? The extra speed gained from the limit
> only achieved by not having to return the data? Or is there some kind of
> magic going on to allow it to ignore certain things about the query when a
> LIMIT is in place?
>
>
> ************
>
>

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026