Scott Marlowe wrote: > On Sun, Dec 7, 2008 at 10:59 PM, M. Edward (Ed) Borasky > <[EMAIL PROTECTED]> 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. > > But I'm sure that if you implemented one that outran XFS / ZFS / ext3 > et. al. people would want to hear about it. > 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.
-- 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éd Rényi via Paul Erdős -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
