Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id B6F38650489 for ; Tue, 9 Dec 2008 10:35:24 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 99822-01-3 for ; Tue, 9 Dec 2008 10:35:20 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mail.postgresql.org (Postfix) with ESMTP id 52633650499 for ; Tue, 9 Dec 2008 10:35:18 -0400 (AST) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id p2ND1a0020mlR8UA62bGmx; Tue, 09 Dec 2008 14:35:16 +0000 Received: from [192.168.1.101] ([71.236.132.25]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id p2bF1a0080Z28Dz8X2bFqA; Tue, 09 Dec 2008 14:35:15 +0000 Message-ID: <493E8245.2020304@cesmail.net> Date: Tue, 09 Dec 2008 06:35:49 -0800 From: "M. Edward (Ed) Borasky" User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: file system and raid performance References: <200812062134.mB6LYw915484@momjian.us> <493CB7B4.3050504@cesmail.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200812/69 X-Sequence-Number: 32105 Scott Marlowe wrote: > On Sun, Dec 7, 2008 at 10:59 PM, M. Edward (Ed) Borasky > wrote: >> Ah, but shouldn't a PostgreSQL (or any other database, for that matter= ) >> have its own set of filesystems tuned to the application's I/O pattern= s? >> Sure, there are some people who need to have all of their eggs in one >> basket because they can't afford multiple baskets. For them, maybe the= >> OS defaults are the right choice. But if you're building a >> database-specific server, you can optimize the I/O for that. >=20 > It's really about a cost / benefits analysis. 20 years ago file > systems were slow and buggy and a database could, with little work, > outperform them. Nowadays, not so much. I'm guessing that the extra > cost and effort of maintaining a file system for pgsql outweighs any > real gain you're likely to see performance wise. >=20 > But I'm sure that if you implemented one that outran XFS / ZFS / ext3 > et. al. people would want to hear about it. >=20 I guess I wasn't clear -- I didn't mean a PostgreSQL-specific filesystem design, although BTRFS does have some things that are "RDBMS-friendly". I meant that one should hand-tune existing filesystems / hardware for optimum performance on specific workloads. The tablespaces in PostgreSQL give you that kind of potential granularity, I think. --=20 M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P), WOM "A mathematician is a device for turning coffee into theorems." -- Alfr=C3=A9d R=C3=A9nyi via Paul Erd=C5=91s