On Tue, Apr 24, 2012 at 4:56 AM, Jan Nielsen <jan.sture.nielsen@xxxxxxxxx> wrote: > We are considering the following drive allocations: > > * 4 x 15k SAS drives, XFS, RAID 10 on SAN for PG data > * 4 x 15k SAS drives, XFS, RAID 10 on SAN for PG indexes > * 2 x 15k SAS drives, XFS, RAID 1 on SAN for PG xlog > * 1 x 15k SAS drive, XFS, on local storage for OS Is it established practice in the Postgres world to separate indexes from tables? I would assume that the reasoning of Richard Foote - albeit for Oracle databases - is also true for Postgres: http://richardfoote.wordpress.com/2008/04/16/separate-indexes-from-tables-some-thoughts-part-i-everything-in-its-right-place/ http://richardfoote.wordpress.com/2008/04/18/separate-indexes-from-tables-some-thoughts-part-ii-there-there/ http://richardfoote.wordpress.com/2008/04/28/indexes-in-their-own-tablespace-availabilty-advantages-is-there-anybody-out-there/ Conversely if you lump both on a single volume you have more flexibility with regard to usage - unless of course you can dynamically resize volumes. To me it also seems like a good idea to mirror local disk with OS and database software because if that fails you'll get downtime as well. As of now you have a single point of failure there. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
