Date: Fri, 16 Jun 2006 07:23:04 -0400
From: Michael Stone <mstone+postgres@mathom.us>
Subject: Re: how to partition disks
In-reply-to: <44901DF7.7010200@aeccom.com>
To: pgsql-performance@postgresql.org
Mail-followup-to: pgsql-performance@postgresql.org
Message-id: <20060616112302.GE29023@mathom.us>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
References: <20060614142344.13558.qmail@web31804.mail.mud.yahoo.com>
	<44901DF7.7010200@aeccom.com>
User-Agent: Mutt/1.5.11+cvs20060403

On Wed, Jun 14, 2006 at 04:32:23PM +0200, Sven Geisler wrote:
>For example, You run two queries with two clients and each queries needs 
>to read some indices from disk. In this case it more efficient to read 
>from different volumes than to read from one large volume where the disc 
>arms has to jump.

Hmm. Bad example, IMO. In the case of reading indices you're doing 
random IO and the heads will be jumping all over the place anyway. The 
limiting factor there will be seeks/s, and you'll possibly get better 
results with the larger array. (That case is fairly complicated to 
analyze and depends very much on the data.) Where multiple arrays will be 
faster is if you have a lot of sequential IO--in fact, a couple of cheap 
disks can blow away a fairly expensive array for purely sequential 
operations since each disk can handle >60MB/s of if it doesn't have to 
seek, whereas multiple sequential streams on the big array will cause 
each disk in the array to seek. (The array controller will try to hide 
this with its cache; its cache size & software will determine how 
successful it is at doing so.)

Mike Stone