Re: slow plan for min/max

Tom Lane wrote:

>"scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
>
>
>>On Mon, 8 Sep 2003, Neil Conway wrote:
>>
>>
>>>As was pointed out in a thread a couple days ago, MIN/MAX() optimization
>>>has absolutely nothing to do with MVCC. It does, however, make
>>>optimizing COUNT() more difficult.
>>>
>>>
>
>
>
>>Not exactly. While max(id) is easily optimized by query replacement,
>>more complex aggregates will still have perfomance issues that would not
>>be present in a row locking database. i.e. max((field1/field2)*field3) is
>>still going to cost more to process, isn't it?
>>
>>
>
>Er, what makes you think that would be cheap in any database?
>
>Postgres would actually have an advantage given its support for
>expressional indexes (nee functional indexes). If we had an optimizer
>transform to convert MAX() into an index scan, I would expect it to be
>able to match up max((field1/field2)*field3) with an index on
>((field1/field2)*field3).
>
>

Would it be possible to rewrite min and max at the parser level into a
select/subselect (clause) condition ( repeat condition ) order by
(clause ) descending/ascending limit 1 and thereby avoiding the
penalties of altering the default aggregate behavior? Would it yield
anything beneficial?