Certainly handling only one case is better than none. I just wanted to
bring up the multiple aggregate scenario. Also, consider that
SELECT min(a), max(a), min(b), max(c) FROM table
could be optimized as well (into 4 index scans, assuming a, b, and c all
had indexes).
I don't think any other aggregates are candidates for optimization right
now, though I guess I could be wrong.
On Thu, Nov 11, 2004 at 05:57:42PM +1300, Mark Kirkwood wrote:
> Your example and ones like :
>
> SELECT max(foo), count(foo) FROM bar
> SELECT max(a.foo1), max(b.foo2) FROM bar1 AS a NATURAL JOIN bar2 AS b
>
> have made me realize that the scope of "what should be optimized" is
> somewhat subtle.
>
> I am inclined to keep it simple (i.e rather limited) for a first cut,
> and if that works well, then look at extending to more complex rewrites.
>
> What do you think?
>
>
> Jim C. Nasby wrote:
>
> >On Thu, Nov 11, 2004 at 11:48:49AM +1300, Mark Kirkwood wrote:
> >
> >
> >>I am looking at implementing this TODO item. e.g. (max case):
> >>
> >>rewrite
> >>SELECT max(foo) FROM bar
> >>as
> >>SELECT foo FROM bar ORDER BY foo DESC LIMIT 1
> >>if there is an index on bar(foo)
> >>
> >>
> >
> >Out of curiosity, will you be doing this in such a way that
> >
> >SELECT min(foo), max(foo) FROM bar
> >
> >will end up as
> >
> >SELECT (SELECT foo FROM bar ORDER BY foo ASC LIMIT 1), (SELECT ... DESC
> >LIMIT 1)
> >
> >?
> >
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
