X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id B3DC9D7133 for ; Tue, 23 Aug 2005 17:13:14 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 74871-09 for ; Tue, 23 Aug 2005 20:13:10 +0000 (GMT) Received: from mail.envyfinancial.com (unknown [206.248.142.186]) by svr1.postgresql.org (Postfix) with ESMTP id AF829D7116 for ; Tue, 23 Aug 2005 17:13:08 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.envyfinancial.com (Postfix) with ESMTP id 21B801D062; Tue, 23 Aug 2005 16:03:43 -0400 (EDT) Received: from mail.envyfinancial.com ([127.0.0.1]) by localhost (mark.mielke.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18870-05; Tue, 23 Aug 2005 16:03:42 -0400 (EDT) Received: by mail.envyfinancial.com (Postfix, from userid 500) id DD1241D069; Tue, 23 Aug 2005 16:03:42 -0400 (EDT) Date: Tue, 23 Aug 2005 16:03:42 -0400 From: mark@mark.mielke.cc To: Donald Courtney Cc: pgsql-performance@postgresql.org, Frank Wiles , gokulnathbabu manoharan Subject: Re: Caching by Postgres Message-ID: <20050823200342.GA18891@mark.mielke.cc> 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=us-ascii Content-Disposition: inline In-Reply-To: <430B6DE3.6040109@sun.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: amavisd-new at mail.envyfinancial.com X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.18 required=5 tests=[AWL=0.002, NO_REAL_NAME=0.178] X-Spam-Level: X-Archive-Number: 200508/353 X-Sequence-Number: 14100 On Tue, Aug 23, 2005 at 02:41:39PM -0400, Donald Courtney wrote: > 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? > From one who likes postgreSQL Hey Donald. :-) This is an operating system issue, not a PostgreSQL issue. If you have more physical memory than fits in 32-bit addresses, and your operating system isn't using this extra memory to cache files (or anything else), than your OS is what I would consider to be broken (or at the very least, not designed for a 64-bit host). The only questions that can be asked here is - 1) can PostgreSQL do a better job than the OS at best utilizing system RAM, and 2) if so, is the net gain worth the added complexity to PostgreSQL? I happen to think that yes, PostgreSQL can do a better job than most OS's, as it has better information to make decisions as to which pages are worth keeping, and which are not, but no, it isn't worth the effort until PostgreSQL developers start running out of things to do. Buy your 64-bit platforms - but if page caching is your concern, 1) ensure that you really have more physical memory than can fit in 32 bits, and 2) ensure that your operating system is comfortable caching data pages from files above the 32-bit mark. Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/