Oopps; looping in the list...
On Tue, Apr 24, 2012 at 8:57 PM, Jan Nielsen <jan.sture.nielsen@xxxxxxxxx> wrote:
On Tue, Apr 24, 2012 at 8:57 PM, Jan Nielsen <jan.sture.nielsen@xxxxxxxxx> wrote:
On Mon, Apr 23, 2012 at 11:53 PM, Robert Klemme <shortcutter@xxxxxxxxxxxxxx> wrote:
On Tue, Apr 24, 2012 at 4:56 AM, Jan NielsenIs it established practice in the Postgres world to separate indexes
<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
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/Very nice articles!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.Agreed.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.Agreed as well.These are good improvements - thanks for the review and references, Robert.
Cheers,Jan
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