After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("scott.marlowe") belched 
> 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

... 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="" in String.concat "@" [name;tld];;
"Cars  move  huge weights at   high    speeds by controlling   violent
explosions many times a second. analogies are always fatal..."

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to