Re: slow plan for min/max

After takin a swig o' Arrakan spice grog, scott(dot)marlowe(at)ihs(dot)com ("scott.marlowe") belched out...:
> On Mon, 8 Sep 2003, Neil Conway wrote:
>> On Mon, 2003-09-08 at 11:56, scott.marlowe wrote:
>> > Basically, Postgresql uses an MVCC locking system that makes massively
>> > parallel operation possible, but costs in certain areas, and one of those
>> > areas is aggregate performance over large sets. MVCC makes it very hard
>> > to optimize all but the simplest of aggregates, and even those
>> > optimzations which are possible would wind up being quite ugly at the
>> > parser level.
>>
>> 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?

That sort of MAX() would be difficult to optimize in almost any case,
and would mandate doing a scan across the relevant portion of the
table...

... Unless you had a functional index on (field1/field2)*field3, in
which case it might well be that this would cost Still Less.

I still can't fathom what this has to do with MVCC; you have yet to
actually connect it with that...
--
let name="cbbrowne" and tld="ntlug.org" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/lsf.html
"Cars move huge weights at high speeds by controlling violent
explosions many times a second. ...car analogies are always fatal..."
-- <westprog(at)my-dejanews(dot)com>