Re: slow plan for min/max

After takin a swig o' Arrakan spice grog, scott.marlowe@ihs.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@my-dejanews.com>