From: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-performance@postgresql.org
Subject: Re: Volunteer to build a configuration tool
Date: Thu, 21 Jun 2007 11:59:14 -0400
Message-ID: <20070621155914.GW5500@phlogiston.dyndns.org> (raw)
In-Reply-To: <Pine.GSO.4.64.0706210244340.29867@westnet.com>
References: <A3AC4FA47DC0B1458C3E5396E685E63302395E53@SAB-DC1.sab.uiuc.edu>
<1182298719.4482.133.camel@ipso.snappymail.ca>
<Pine.GSO.4.64.0706200040001.7594@westnet.com>
<7621.1182318230@sss.pgh.pa.us>
<Pine.GSO.4.64.0706200224430.16657@westnet.com>
<9001.1182323187@sss.pgh.pa.us>
<op.tt7mn0m9cigqcu@apollo13>
<Pine.GSO.4.64.0706201044100.9089@westnet.com>
<A3AC4FA47DC0B1458C3E5396E685E63302395E6C@SAB-DC1.sab.uiuc.edu>
<Pine.GSO.4.64.0706210244340.29867@westnet.com>
On Thu, Jun 21, 2007 at 03:14:48AM -0400, Greg Smith wrote:
> "The Oracle Way" presumes that you've got such a massive development staff
> that you can solve these problems better yourself than the community at
> large, and then support that solution on every platform.
Not that Greg is suggesting otherwise, but to be fair to Oracle (and
other large database vendors), the raw partitions approach was also a
completely sensible design decision back when they made it. In the
late 70s and early 80s, the capabilities of various filesystems were
wildly uneven (read the _UNIX Hater's Handbook_ on filesystems, for
instance, if you want an especially jaundiced view). Moreover, since
it wasn't clear that UNIX and UNIX-like things were going to become
the dominant standard -- VMS was an obvious contender for a long
time, and for good reason -- it made sense to have a low-level
structure that you could rely on.
Once they had all that code and had made all those assumptions while
relying on it, it made no sense to replace it all. It's now mostly
mature and robust, and it is probably a better decision to focus on
incremental improvements to it than to rip it all out and replace it
with something likely to be buggy and surprising. The PostgreSQL
developers' practice of sighing gently every time someone comes along
insisting that threads are keen or that shared memory sucks relies on
the same, perfectly sensible premise: why throw away a working
low-level part of your design to get an undemonstrated benefit and
probably a whole lot of new bugs?
A
--
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ajs@crankycanuck.ca
Subject: Re: Volunteer to build a configuration tool
In-Reply-To: <20070621155914.GW5500@phlogiston.dyndns.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox