Re: For the ametures. (related to "Are we losing - Mailing list pgsql-hackers

From Matthew T. O'Connor
Subject Re: For the ametures. (related to "Are we losing
Date
Msg-id 1051014203.15057.16.camel@zeutrh9
Whole thread Raw
In response to Re: For the ametures. (related to "Are we losing momentum?")  (Ben Clewett <B.Clewett@roadrunner.uk.com>)
List pgsql-hackers
On Tue, 2003-04-22 at 04:25, Ben Clewett wrote:
> Matthew T. O'Connor wrote:
> From my data/base directory, I have a tree structure of numbered files 
> of no obvious structure.  As well as some smaller directories, 'global', 
> 'pg_xlog' and 'pg_clog'.
> 
> If I wanted to divide the postmaster read() calls evenly to files 
> located over several physical disks, how would you suggest distributing 
> the data-space?  Would it be as simple as putting each child directory 
> in 'data/base' on a different physical disk in a round-robbin fasion 
> using symbolic links:  Or is it more involved...
> 
> data/base/1 -> /dev/hda
> data/base/2 -> /dev/hdb
> data/base/3 -> /dev/hdc
> data/base/4 -> /dev/hda
> data/base/5 -> /dev/hdb
> data/base/6 -> /dev/hdc (etc)
> 
> (I have made the assumption that the postmaster serves different 
> connections in parallel, otherwise this would have little effect :)

Yes connections are served in parallel.  The best way to split the files
is something you have to figure out, probably based on usage.  The round
robin directory method you mentioned above falls down in that it only
splits whole databases into different locations regardless of how much
I/O is related to those databases.  You may wind up with inactive
databases on their own disk which would yield no performance gain.  It's
also probably better to get down to the file / index level rather than
whole databases as you may have a few tables that get 90% of the work.

Hopefully some of that was helpful.



pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: bit strings - anyone working on them?
Next
From: Peter Eisentraut
Date:
Subject: Re: CLOSE command tag