control of benchmarks (was: [PERFORM] Thousands of tables)

[Andrew Sullivan]

On Wed, Jun 06, 2007 at 02:01:59PM -0400, Jonah H. Harris wrote:
 They did this for the same reason as everyone else.  They don't want
 non-experts tuning the database incorrectly, writing a benchmark paper
 about it, and making the software look bad.

I agree that Oracle is a fine system, and I have my doubts about the
likelihood Oracle will fall over under fairly heavy loads.  But I
think the above is giving Oracle Corp a little too much credit. 

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.  Every user of any large
software system (Oracle or otherwise) has their favourite horror
story about the grotty corners of that software;
commercially-licensed people just aren't allowed to prove it in
public.  It's not only the clueless Oracle is protecting themselves
against; it's also the smart, accurate, but expensive corner-case
testers.  I get to complain that PostgreSQL is mostly fast but has
terrible outlier performance problems.  I can think of another system
that I've used that certainly had a similar issue, but I couldn't
show you the data to prove it.  Everyone who used it knew about it,
though.

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off.
--Alexander Hamilton

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: control of benchmarks (was: [PERFORM] Thousands of tables)

[Jonah H. Harris]

On 6/6/07, Andrew Sullivan [EMAIL PROTECTED] 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| [EMAIL PROTECTED]
Iselin, New Jersey 08830| http://www.enterprisedb.com/

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match