From: | Michael Stone <mstone+postgres(at)mathom(dot)us> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Storage Options |
Date: | 2006-08-22 10:02:38 |
Message-ID: | 20060822100236.GW2900@mathom.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Aug 21, 2006 at 02:50:51PM -0700, Jeff Davis wrote:
>the NetApp over NFS, so I am not sure what performance to expect. Any
>suggestions about using network storage like this for the database?
Don't. Unless you're using a very small (toy-scale) database, the netapp
storage is way too expensive for the kind of usage you see with a
database application. You're much better off buying much cheaper storage
twice and using a database replication solution than either choking a
really expensive netapp or getting lousy performance from the same. The
netapps have their niche, but database storage isn't it. (Peformance in
general really isn't it--the advantages are managability, snapshotting,
and cross-platform data exchange. It may be that those factors are
important enough to make that a good solution for your particular
situation, but they're generally not particularly relevant in the
postgres space.)
>Is there any consensus on whether to do WAL on a RAID-1 and PGDATA on a
>RAID-10 versus everything on a RAID-10? How does the number of disks I
>have affect this decision (I will probably have 4-8 disks per server).
You can't get a good answer without testing with your actual data. I'd
suspect that with such a low number of disks you're better off with a
single array, assuming that you have a good bbu raid controller and
assuming that you're not doing write-mostly transaction work. But
testing with your actual workload is the only way to really know.
Mike Stone
From | Date | Subject | |
---|---|---|---|
Next Message | Ravindran G - TLS, Chennai. | 2006-08-22 12:39:21 | Postgre SQL 7.1 cygwin performance issue. |
Previous Message | Dan Langille | 2006-08-22 09:09:36 | Forcing index usage without 'enable_hashjoin = FALSE' |