| From: | Alex Turner <armtuk(at)gmail(dot)com> |
|---|---|
| To: | Douglas McNaught <doug(at)mcnaught(dot)org> |
| Cc: | felix(at)crowfix(dot)com, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Generic Q about max(id) vs ORDER BY ID DESC LIMIT 1 |
| Date: | 2005-10-24 23:14:43 |
| Message-ID: | 33c6269f0510241614k43306e45xcfbab656541b3c1e@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
I believe based on semi-recent posts that MIN and MAX are now treated
as special cases in 8.1, and are synonymous with select id order by id
desc limit 1 etc..
Alex
On 10/24/05, Douglas McNaught <doug(at)mcnaught(dot)org> wrote:
> felix(at)crowfix(dot)com writes:
>
> > However, in the process of investigating this, my boss found something
> > which we do not understand. A table with a primary key 'id' takes 200
> > seconds to SELECT MAX(id), but is as close to instantaneous as you'd
> > want for SELECT ID ORDER BY ID DESC LIMIT 1. I understand why
> > count(*) has to traverse all records, but why does MAX have to? This
> > table has about 750,000 rows, rather puny.
>
> As I understand it, because aggregates in PG are extensible (the query
> planner just knows it's calling some function), MAX isn't specially
> handled--the planner doesn't know it's equivalent to the other query.
>
> There has been some talk of special-casing this, but I'm not sure
> where it lead--you might check the archives.
>
> -Doug
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | felix | 2005-10-24 23:21:57 | Re: Generic Q about max(id) vs ORDER BY ID DESC LIMIT 1 -- SOLVED |
| Previous Message | Jamie Deppeler | 2005-10-24 23:11:16 | Autogenerated backup of a password protected database |