Skip site navigation (1) Skip section navigation (2)

Re: slow plan for min/max

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: slow plan for min/max
Date: 2003-09-08 21:41:43
Message-ID: m3d6ebvtyg.fsf@chvatal.cbbrowne.com (view raw or flat)
Thread:
Lists: pgsql-performance
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>

In response to

pgsql-performance by date

Next:From: Alberto CasoDate: 2003-09-08 22:04:40
Subject: Re: [PERFORM] Explain Doc
Previous:From: Tom LaneDate: 2003-09-08 21:26:16
Subject: Re: slow plan for min/max

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group