Re: For the ametures. (related to "Are we losing

Поиск
Список
Период
Сортировка
От Matthew T. O'Connor
Тема Re: For the ametures. (related to "Are we losing
Дата
Msg-id 1051014203.15057.16.camel@zeutrh9
обсуждение исходный текст
Ответ на Re: For the ametures. (related to "Are we losing momentum?")  (Ben Clewett <B.Clewett@roadrunner.uk.com>)
Список 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 по дате отправления:

Предыдущее
От: Philip Warner
Дата:
Сообщение: bit strings - anyone working on them?
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: CLOSE command tag