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 [EMAIL PROTECTED] 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?" ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]