From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | leonbloy(at)sinectis(dot)com(dot)ar |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: btree index and max() |
Date: | 2000-06-01 21:42:07 |
Message-ID: | 26387.959895727@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
leonbloy(at)sinectis(dot)com(dot)ar writes:
> I understand that the query planner cannot be so clever
> to grasp that this particular function (max or min)
> might be evaluated by just travelling the BTREE index.
> Am I correct?
You are correct --- the system has no idea that there is any
connection between the MIN and MAX aggregates and the sort order
of any particular index. (In fact, the system knows nothing
about the specific semantics of any aggregate function; they're
all black boxes, which is a very good thing for most purposes.)
However, if you think of your problem as "how can I use the sort order
of this index to get the min/max?", a semi-obvious answer pops out:
SELECT foo FROM table ORDER BY foo LIMIT 1; -- get the min
SELECT foo FROM table ORDER BY foo DESC LIMIT 1; -- get the max
and the 7.0 optimizer does indeed know how to use an index to handle
these queries.
Perhaps someday we will try to convert simple uses of MIN/MAX into
queries like these, but for now, you gotta do it by hand.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-06-01 21:58:33 | Re: Postmaster won't -HUP |
Previous Message | Jerry Lynde | 2000-06-01 21:29:02 | Re: Postmaster won't -HUP |