Date: Mon, 14 Aug 2006 10:38:41 -0500
From: "Jim C. Nasby" <jnasby@pervasive.com>
To: pgsql-performance@postgresql.org
Subject: Re: Postgresql Performance on an HP DL385 and
Message-ID: <20060814153841.GF27928@pervasive.com>
References: <3E37B936B592014B978C4415F90D662D03FFEF6E@MI8NYCMAIL06.Mi8.com>
	<721b21dc0608082245u6ee62e7dg522ff18e4d72683@mail.gmail.com>
	<20060809210539.GR40481@pervasive.com>
	<1155180553.13315.0.camel@amd64-gentoo-laptop>
	<20060810110935.GF2900@mathom.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060810110935.GF2900@mathom.us>
User-Agent: Mutt/1.5.11

On Thu, Aug 10, 2006 at 07:09:38AM -0400, Michael Stone wrote:
> On Wed, Aug 09, 2006 at 08:29:13PM -0700, Steve Poe wrote:
> >I tried as you suggested and my performance dropped by 50%. I went from
> >a 32 TPS to 16. Oh well.
> 
> If you put data & xlog on the same array, put them on seperate 
> partitions, probably formatted differently (ext2 on xlog).

Got any data to back that up?

The problem with seperate partitions is that it means more head movement
for the drives. If it's all one partition the pg_xlog data will tend to
be interspersed with the heap data, meaning less need for head
repositioning.

Of course, if ext2 provided enough of a speed improvement over ext3 with
data=writeback then it's possible that this would be a win, though if
the controller is good enough to make putting pg_xlog on the same array
as $PGDATA a win, I suspect it would make up for most filesystem
performance issues associated with pg_xlog as well.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461