Skip site navigation (1) Skip section navigation (2)

Re: file system and raid performance

From: david(at)lang(dot)hm
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: "M(dot) Edward (Ed) Borasky" <znmeb(at)cesmail(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Mark Mielke <mark(at)mark(dot)mielke(dot)cc>, Greg Smith <gsmith(at)gregsmith(dot)com>, Mark Wong <markwkm(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: file system and raid performance
Date: 2008-12-08 20:51:39
Message-ID: alpine.DEB.1.10.0812081251090.13350@asgard.lang.hm (view raw or flat)
Thread:
Lists: pgsql-performance
On Mon, 8 Dec 2008, Scott Marlowe wrote:

> On Sun, Dec 7, 2008 at 10:59 PM, M. Edward (Ed) Borasky
> <znmeb(at)cesmail(dot)net> 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 patterns?
>> 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.
>
> 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.

especially with the need to support the new 'filesystem' on many different 
OS types.

David Lang

> But I'm sure that if you implemented one that outran XFS / ZFS / ext3
> et. al. people would want to hear about it.
>
>

In response to

pgsql-performance by date

Next:From: Greg SmithDate: 2008-12-08 22:52:30
Subject: Re: Need help with 8.4 Performance Testing
Previous:From: Scott MarloweDate: 2008-12-08 20:31:29
Subject: Re: Need help with 8.4 Performance Testing

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group