| From: | Douglas McNaught <doug(at)mcnaught(dot)org> |
|---|---|
| To: | felix(at)crowfix(dot)com |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Generic Q about max(id) vs ORDER BY ID DESC LIMIT 1 |
| Date: | 2005-10-24 22:44:12 |
| Message-ID: | m2hdb6o7r7.fsf@Douglas-McNaughts-Powerbook.local |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | felix | 2005-10-24 22:50:57 | Re: Generic Q about max(id) vs ORDER BY ID DESC LIMIT 1 |
| Previous Message | Scott Marlowe | 2005-10-24 22:34:15 | Re: PostgreSQL vs mySQL, any performance difference for |