> 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?

Sorry, no.   

The issue has nothing to do with MVCC.   It has everything to do with the fact 
that PostgreSQL allows you to create your own aggregates using functions in 
any of 11 languages.   This forces the planner to treat aggregates as a 
"black box" which does not allow index utilization, because the planner 
simply doesn't know what the aggregate is doing internally.

To put it another way, the planner sees SUM() or CONCAT() -- which require 
table scans as they must include all values -- as identical to MAX() and 

Escaping this would require programming a special exception for MAX() and 
MIN() into the planner and parser.   This has been discussed numerous times 
on HACKERS; the problem is, making special exceptions for MAX() and MIN() 
would then make it very difficult to implement MAX() or MIN() for new data 
types, as well as requiring a lot of debugging in numerous places.   So far, 
nobody has been frustrated enough to spend 3 months tackling the problem.

-Josh Berkus
 Aglio Database Solutions
 San Francisco

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to