Skip site navigation (1) Skip section navigation (2)

Re: Two hard drives --- what to do with them?

From: Alexander Staubo <alex(at)purefiction(dot)net>
To: Carlos Moreno <moreno_pg(at)mochima(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Two hard drives --- what to do with them?
Date: 2007-02-25 04:08:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Feb 25, 2007, at 04:39 , Carlos Moreno wrote:

> I do have the option to configure it in RAID-0, but I'm sort of  
> reluctant;  I think
> there's the possibility that having two filesystems that can be  
> accessed truly
> simultaneously can be more beneficial.  The question is:  does  
> PostgreSQL
> have separate, independent areas that require storage such that  
> performance
> would be noticeably boosted if the multiple storage operations  
> could be done
> simultaneously?

Putting the WAL (aka pg_xlog) on a separate disk will take some load  
off your main database disk. See 
Tidbits/perf.html for this.

It is also possible to put individual tables and/or indexes on  
separate disks by using tablespaces: "For example, an index which is  
very heavily used can be placed on a very fast, highly available  
disk, such as an expensive solid state device. At the same time a  
table storing archived data which is rarely used or not performance  
critical could be stored on a less expensive, slower disk  
system." ( 

In both cases, the performance benefits tend to be relative to the  
amount of write activity you experience, and the latter solution  
assumes you know where the hotspots are. If you have two tables that  
see continuous, intense write activity, for example, putting each on  
a separate disk


In response to

pgsql-performance by date

Next:From: Peter KovacsDate: 2007-02-25 22:11:01
Subject: Re: Two hard drives --- what to do with them?
Previous:From: Tom LaneDate: 2007-02-25 03:58:51
Subject: Re: Two hard drives --- what to do with them?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group