On Thu, 2006-05-25 at 16:52 -0400, Tom Lane wrote: > "Merlin Moncure" <mmoncure@xxxxxxxxx> writes: > > been doing a lot of pgsql/mysql performance testing lately, and there > > is one query that mysql does much better than pgsql...and I see it a > > lot in normal development: > > > select a,b,max(c) from t group by a,b; > > > t has an index on a,b,c. > > The index won't help, as per this comment from planagg.c: > > * We don't handle GROUP BY, because our current implementations of > * grouping require looking at all the rows anyway, and so there's not > * much point in optimizing MIN/MAX. > > Given the numbers you mention (300k rows in 2000 groups) I'm not > convinced that an index-based implementation would help much; we'd > still need to fetch at least one record out of every 150, which is > going to cost near as much as seqscanning all of them. Well, if the MySQL server has enough RAM that the index is cached (or index + relevant chunks of data file if using InnoDB?) then that would explain how MySQL can use an index to get fast results. -- Mark Lewis
