Keith: I think it would be great to get the optimizer to do something smart on such a simple (and common) query. I am porting an app to Postgresql and I am not looking forward to having to fix all the postgres-ism that seem trivial like this. Postgres gets a bad rap for this kinda simple qweak that makes out of the box queries perform slowly and I'd like to help improve the image.
Let me know if you need another tester for the fixes. Currently on 7.2. here (7.2.3. I memory serves correct). Charlie Keith Gray wrote: > Richard Huxton wrote: > >>>> As of now, Max() doesn't utilizes the indices hence >>>> it always do a sequential scan. >>> > > >>> Is this likely to be sorted in 7.2 ? >>> Is anyone looking at this? >> > > >> As I understand, the problem is that the optimisation only applies >> for simple cases... > > > > Getting MIN() adn MAX() seems fairly trivial to me. > > When is on an index or more importantly Primary > Key it must be a common SQL. > > Would it be possible in the code to look at > the field in MIN() or MAX() and if it is > indexed use a similar method to the suggested > SQL work around? > > Can I help this to happen? > > > -- Charles H. Woloszynski ClearMetrix, Inc. 115 Research Drive Bethlehem, PA 18015 tel: 610-419-2210 x400 fax: 240-371-3256 web: www.clearmetrix.com ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
