From: Chris Browne <cbbrowne@acm.org>
Subject: Re: Caching by Postgres
Date: Tue, 23 Aug 2005 16:41:33 -0400
Organization: cbbrowne Computing Inc
Lines: 29
Message-ID: <60slx0perm.fsf@dba2.int.libertyrms.com>
References: <20050823171045.12112.qmail@web51309.mail.yahoo.com>
	<20050823124323.710a9dd3.frank@wiles.org>
	<430B6DE3.6040109@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (Jumbo Shrimp, linux)
Cancel-Lock: sha1:Z88FuvlZon01WvzFSgLpygDCH2g=
To: pgsql-performance@postgresql.org

Donald.Courtney@Sun.COM (Donald Courtney) writes:
> I mean well with this comment -
> This whole issue of data caching is  a troubling issue with postreSQL
> in that even if you ran postgreSQL on a 64 bit address space
> with larger number of CPUs you won't see much of a scale up
> and possibly even a drop.   I am not alone in having the *expectation*
> that a database should have some cache size parameter and
> the option to skip the file system.   If I use oracle, sybase, mysql
> and maxdb they all have the ability to size a data cache and move
> to 64 bits.
>
> Is this a crazy idea - that a project be started to get this
> adopted?  Is it too big and structural to contemplate?

This project amounts to "Implement Your Own Operating System," because
it requires that the DBMS take over the things that operating systems
normally do, like:
 a) Managing access to filesystems and
 b) Managing memory

The world is already sufficiently filled up with numerous variations
of Linux, BSD 4.4 Lite, and UNIX System V; I can't see justification for
reinventing this wheel still again.
-- 
(format nil "~S@~S" "cbbrowne" "acm.org")
http://cbbrowne.com/info/multiplexor.html
Rules of  the Evil Overlord #196.  "I will hire an  expert marksman to
stand by the entrance to my  fortress. His job will be to shoot anyone
who rides up to challenge me."  <http://www.eviloverlord.com/>