Tom Lane wrote: >"scott.marlowe" <[EMAIL PROTECTED]> 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? ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
