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 76CCB52DEF for ; Sat, 20 Aug 2005 08:18:04 -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 75198-07 for ; Sat, 20 Aug 2005 11:18:00 +0000 (GMT) Received: from fep32-app.kolumbus.fi (fep32-0.kolumbus.fi [193.229.0.63]) by svr1.postgresql.org (Postfix) with ESMTP id 60CCE52DE2 for ; Sat, 20 Aug 2005 08:17:56 -0300 (ADT) Received: from [192.168.1.101] (really [80.186.78.229]) by fep32-app.kolumbus.fi with ESMTP id <20050820111758.QSZF27630.fep32-app.kolumbus.fi@[192.168.1.101]> for ; Sat, 20 Aug 2005 14:17:58 +0300 Message-ID: <43071162.6050405@kolumbus.fi> Date: Sat, 20 Aug 2005 14:17:54 +0300 From: Marko Ristola User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: pgsql-performance@postgresql.org Subject: Re: extremly low memory usage References: <1124331108.27881.96.camel@bluejay.goodinassociates.com> <1124386761.27881.119.camel@bluejay.goodinassociates.com> <4304CB77.4070403@arbash-meinel.com> <1124470109.27881.152.camel@bluejay.goodinassociates.com> <43061472.2080201@arbash-meinel.com> <6.2.3.4.0.20050819140714.05c181e8@pop.earthlink.net> <43063196.9000001@arbash-meinel.com> <1124485299.27881.192.camel@bluejay.goodinassociates.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.128 required=5 tests=[AWL=0.078, FORGED_RCVD_HELO=0.05] X-Spam-Level: X-Archive-Number: 200508/288 X-Sequence-Number: 14035 Dan Harris wrote: > From my recent experiences, I can say ext3 is probably not a great > choice for Pg databases. If you check the archives you'll see > there's a lot of discussion about various journalling filesystems and > ext3 usually(always?) comes up on the bottom as far as performance > goes. If you insist on using it, I would at least recommend the > noatime option in fstab and using data=writeback to get the faster Based on my knoledge, Ext3 is good with keeping filesystem integrity AND data integrity while pressing the reset button. However, by selecting data=writeback, you gain more speed, but you risk the data integrity during a crash: Ext3 garantees only filesystem integrity. This means with database transaction logs: The last transactions are not guaranteed to be written into the hard drives during a hardware reset, meaning of a loss of some committed transactions. Reiserfs is known to do things this false way also. Is there a way with a Reiserfs filesystem to fulfill both filesystem AND data integrity requirements nowadays? See for example "man mount" to see the effects of data=journal, data=ordered(default) and data=writeback for Ext3. Only the writeback risks data integrity. Ext3 is the only journaled filesystem, that I know that fulfills these fundamental data integrity guarantees. Personally I like about such filesystems, even though it means less speed. Marko Ristola