DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=KJZ5LgGrGdM167Lzk2RRxAg5HclGf7ZDgifZWiYb/GXeaUYDHxHZuiDLQk3eWxn8dBjxfz57/DZFJSg/ROCmIsol6xJfQB5ASlgvGdQKoqI24ad++OU6jmyrZPx3kxca593dwdHYAGUw5jmFNKkdxdqHVYAAmLz7fuWDEpHtLT8=
Message-ID: <36e682920706061257l3a4817c1j413c74697cbf5762@mail.gmail.com>
Date: Wed, 6 Jun 2007 15:57:08 -0400
From: "Jonah H. Harris" <jonah.harris@gmail.com>
To: "Andrew Sullivan" <ajs@crankycanuck.ca>
Subject: Re: control of benchmarks (was: Thousands of tables)
Cc: pgsql-performance@postgresql.org
In-Reply-To: <20070606194058.GE11545@phlogiston.dyndns.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <877iqjmro5.fsf@oxford.xeocode.com>
	<Pine.LNX.4.64.0706041631490.11737@asgard.lang.hm>
	<466593E5.1010904@g2switchworks.com>
	<87sl96z0wf.fsf@oxford.xeocode.com>
	<Pine.LNX.4.64.0706051325500.24361@asgard.lang.hm>
	<10525.1181080765@sss.pgh.pa.us>
	<Pine.LNX.4.64.0706051507120.24361@asgard.lang.hm>
	<4666DF99.3010809@emolecules.com>
	<36e682920706061101i5d3344c2idc518c6190b0af77@mail.gmail.com>
	<20070606194058.GE11545@phlogiston.dyndns.org>

On 6/6/07, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
> But I think the above is giving Oracle Corp a little too
> much credit.

Perhaps.  However, Oracle has a thousand or so knobs which can control
almost every aspect of every subsystem.  If you know how they interact
with each other and how to use them properly, they can make a huge
difference in performance.  Most people do not know all the knobs or
understand what difference each can make given the theory and
architecture of the system, which results in poor general
configurations.  Arguably, there is a cost associated with having
someone staffed and/or consulted that has the depth of knowledge
required to tune it in such a manner which goes back to a basic
cost/benefit analysis.

Oracle, while seeming like a one-size-fits-all system, has the same
basic issue as PostgreSQL and everyone else; to get optimum
performance, it has to be tuned specifically for the
application/workload at hand.

> Corporations exist to make money, and the reason they prohibit doing
> anything with their software and then publishing it without their
> approval is because they want to control all the public perception of
> their software, whether deserved or not.

Of course.  Which is why audited benchmarks like SPEC and TPC are
around.  While they may not represent one's particular workload, they
are the only way to fairly demonstrate comparable performance.

> Every user of any large software system (Oracle or otherwise)
> has their favourite horror story about the grotty corners of
> that software;

Of course, but they also never say why it was caused.  With Oracle,
almost all bad-performance cases I've seen are related to improper
tuning and/or hardware; even by experienced DBAs.

-- 
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation            | fax: 732.331.1301
33 Wood Ave S, 3rd Floor            | jharris@enterprisedb.com
Iselin, New Jersey 08830            | http://www.enterprisedb.com/