After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("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..." -- <[EMAIL PROTECTED]> ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend