| From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | "M(dot) Edward (Ed) Borasky" <znmeb(at)cesmail(dot)net> |
| Cc: | "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 16:05:37 |
| Message-ID: | dcc563d10812080805l4b455776r62504e51d01f1e06@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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.
But I'm sure that if you implemented one that outran XFS / ZFS / ext3
et. al. people would want to hear about it.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2008-12-08 20:15:36 | Re: Need help with 8.4 Performance Testing |
| Previous Message | Jean-David Beyer | 2008-12-08 12:15:22 | Re: file system and raid performance |