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
thepostgres-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
