Re: [SQL] trivial problem

From: "Moray McConnachie" <moray(dot)mcconnachie(at)computing-services(dot)oxford(dot)ac(dot)uk>
To: <tjk(at)tksoft(dot)com>, "Roderick A(dot) Anderson" <raanders(at)altoplanos(dot)net>
Cc: <oleg(at)sai(dot)msu(dot)su>, <pgsql-sql(at)postgresql(dot)org>
Subject: Re: [SQL] trivial problem
Date: 1999-10-29 20:02:00
Message-ID: 003101bf2248$76e0d8e0$9f1b4cc0@public.ox.ac.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql


----- 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?

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 1999-10-29 20:19:57 Re: [SQL] trivial problem
Previous Message Werner Reisberger 1999-10-29 19:36:03 tuning large selects