Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id CEEE12E002F for ; Fri, 16 May 2008 14:07:24 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 59179-02 for ; Fri, 16 May 2008 14:07:17 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.234]) by developer.postgresql.org (Postfix) with ESMTP id 429A02E0053 for ; Fri, 16 May 2008 14:07:18 -0300 (ADT) Received: by qb-out-0506.google.com with SMTP id a39so843509qbd.17 for ; Fri, 16 May 2008 10:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=RQT9BQCcqjYZOZLvLhQYvtY6wDGBmJtg3cfRiultsB0=; b=nHmAhiRuYouzhYRuJstWXf+x+W1DvhLh++zuAU54m1f9uumXtwmeVl8lPgQhMH97DAkL9oAkRgnaniTXfnoNqFasRo3w9jHJ4pf+fFvePrhAR4eHxRcoQHAu1ABjrN7C3vWr/I0UWGg9kb9Z6rnD7doyj3Um7DsTniHTolSMsi0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pGTc9Bkb+dSGJ6qYiGEnixaLuLwJ9bi7ZdlXjqy9EUaeGQHRr6paGSXGQVJvxvKeDiqxWBdFy6Fqg4xchVwddx91bcIqMHUkkezgrInJl2EaLf9egtj1Daoq64hP3gnShwEYLbrrfk3rMwe8+T9i1Jnpv2O72iCHZtbgP7Fqhr4= Received: by 10.115.18.3 with SMTP id v3mr3904504wai.218.1210957637108; Fri, 16 May 2008 10:07:17 -0700 (PDT) Received: by 10.114.137.7 with HTTP; Fri, 16 May 2008 10:07:17 -0700 (PDT) Message-ID: Date: Fri, 16 May 2008 11:07:17 -0600 From: "Scott Marlowe" To: "Joshua D. Drake" Subject: Re: which ext3 fs type should I use for postgresql Cc: "Guillaume Cottenceau" , "Matthew Wakeling" , "pgsql-performance@postgresql.org" In-Reply-To: <482C58EA.5090904@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1210846262.16664.41.camel@philippe-desktop> <482C4F3D.6010808@emolecules.com> <87ve1fwqov.fsf@mnc.ch> <87r6c3wpka.fsf@mnc.ch> <482C58EA.5090904@commandprompt.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/245 X-Sequence-Number: 30213 On Thu, May 15, 2008 at 9:38 AM, Joshua D. Drake wrote: > Guillaume Cottenceau wrote: >> >> Matthew Wakeling writes: > >> It is still relevant, as with 5% margin, you can afford changing >> that to 0% with tune2fs, just the time for you to start PG and >> remove some data by SQL, then shutdown and set the margin to 5% >> again. >> > > I find that if you actually reach that level of capacity failure it is due > to lack of management and likely there is much lower hanging fruit left over > by a lazy dba or sysadmin than having to adjust filesystem level parameters. > > Manage actively and the above change is absolutely irrelevant. Sorry, but that's like saying that open heart surgery isn't a fix for clogged arteries because you should have been taking aspirin everyday and exercising. It might not be the best answer, but sometimes it's the only answer you've got. I know that being able to drop the margin from x% to 0% for 10 minutes has pulled more than one db back from the brink for me (usually consulting on other people's databases, only once or so on my own) :)