Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 42164633D0A for ; Tue, 9 Mar 2010 09:49:14 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 77462-03 for ; Tue, 9 Mar 2010 13:49:03 +0000 (UTC) X-Greylist: delayed 00:06:39.369203 by SQLgrey-1.7.6 Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by mail.postgresql.org (Postfix) with SMTP id 732B8633B70 for ; Tue, 9 Mar 2010 09:49:03 -0400 (AST) Received: (qmail 2422 invoked by uid 503); 9 Mar 2010 13:45:02 -0000 Received: from b9.ovh.net (HELO mail623.ha.ovh.net) (213.186.33.59) by 27.mail-out.ovh.net with SMTP; 9 Mar 2010 13:45:01 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 9 Mar 2010 13:42:41 -0000 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO localhost) (lists%peufeu.com@88.161.102.87) by ns0.ovh.net with SMTP; 9 Mar 2010 13:42:40 -0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Greg Smith" , "Scott Carey" Cc: "" , "Scott Marlowe" , "Francisco Reyes" , "Pgsql performance" Subject: Re: 10K vs 15k rpm for analytics References: <06A22EB5-2D84-401C-B75F-7CA883695E0A@richrelevance.com> <4B95F222.6040504@2ndquadrant.com> Date: Tue, 09 Mar 2010 14:39:22 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Pierre C" Message-ID: In-Reply-To: <4B95F222.6040504@2ndquadrant.com> User-Agent: Opera Mail/10.10 (Linux) X-Ovh-Tracer-Id: 5787125522984863383 X-Ovh-Remote: 88.161.102.87 (par69-8-88-161-102-87.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/89 X-Sequence-Number: 37914 On Tue, 09 Mar 2010 08:00:50 +0100, Greg Smith wrote: > Scott Carey wrote: >> For high sequential throughput, nothing is as optimized as XFS on Linux >> yet. It has weaknesses elsewhere however. >> When files are extended one page at a time (as postgres does) fragmentation can be pretty high on some filesystems (ext3, but NTFS is the absolute worst) if several files (indexes + table) grow simultaneously. XFS has delayed allocation which really helps. > I'm curious what you feel those weaknesses are. Handling lots of small files, especially deleting them, is really slow on XFS. Databases don't care about that. There is also the dark side of delayed allocation : if your application is broken, it will manifest itself very painfully. Since XFS keeps a lot of unwritten stuff in the buffers, an app that doesn't fsync correctly can lose lots of data if you don't have a UPS. Fortunately, postgres handles fsync like it should be. A word of advice though : a few years ago, we lost a few terabytes on XFS (after that, restoring from backup was quite slow !) because a faulty SCSI cable crashed the server, then crashed it again during xfsrepair. So if you do xfsrepair on a suspicious system, please image the disks first.