X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id C31ED9DD6A1 for ; Thu, 1 Dec 2005 14:57:37 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 31975-01-2 for ; Thu, 1 Dec 2005 14:57:34 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 7BAC39DD699 for ; Thu, 1 Dec 2005 14:57:34 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id jB1IvXNr015740; Thu, 1 Dec 2005 13:57:33 -0500 (EST) To: Ron cc: Tino Wildenhain , pgsql-performance@postgresql.org Subject: Re: 15,000 tables In-reply-to: <6.2.5.6.0.20051201134344.035fed60@earthlink.net> References: <9A858930-1CA6-4238-92D4-D1E945683653@ehpg.net> <1133462407.5734.43.camel@Andrea.peacock.de> <6.2.5.6.0.20051201134344.035fed60@earthlink.net> Comments: In-reply-to Ron message dated "Thu, 01 Dec 2005 13:48:11 -0500" Date: Thu, 01 Dec 2005 13:57:33 -0500 Message-ID: <15739.1133463453@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200512/36 X-Sequence-Number: 15857 Ron writes: > Agreed. Also the odds of fs corruption or data loss are higher in a > non journaling fs. Best practice seems to be to use a journaling fs > but to put the fs log on dedicated spindles separate from the actual > fs or pg_xlog. I think we've determined that best practice is to journal metadata only (not file contents) on PG data filesystems. PG does expect the filesystem to remember where the files are, so you need metadata protection, but journalling file content updates is redundant with PG's own WAL logging. On a filesystem dedicated to WAL, you probably do not need any filesystem journalling at all --- we manage the WAL files in a way that avoids changing metadata for a WAL file that's in active use. A conservative approach would be to journal metadata here too, though. regards, tom lane