To: Scott Carey <scott@richrelevance.com>
cc: Greg Smith <greg@2ndquadrant.com>, Tom Wilcox <hungrytom@gmail.com>,
	Bob Lunney <bob_lunney@yahoo.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: requested shared memory size overflows size_t 
In-reply-to: <08A32E7F-5FFC-4341-A543-E0BFB6420B7E@richrelevance.com> 
References: <584872.74177.qm@web39702.mail.mud.yahoo.com>
	<4C167A8D.1060002@gmail.com> <4C16E039.10803@2ndquadrant.com>
	<08A32E7F-5FFC-4341-A543-E0BFB6420B7E@richrelevance.com>
Comments: In-reply-to Scott Carey <scott@richrelevance.com>
	message dated "Mon, 14 Jun 2010 20:49:40 -0700"
Date: Mon, 14 Jun 2010 23:57:11 -0400
Message-ID: <26740.1276574231@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Scott Carey <scott@richrelevance.com> writes:
> Great points.  There is one other option that is decent for the WAL:
> If splitting out a volume is not acceptable for the OS and WAL -- absolutely split those two out into their own partitions.  It is most important to make sure that WAL and data are not on the same filesystem, especially if ext3 is involved.

Uh, no, WAL really needs to be on its own *spindle*.  The whole point
here is to have one disk head sitting on the WAL and not doing anything
else except writing to that file.  Pushing WAL to a different partition
but still on the same physical disk is likely to be a net pessimization,
because it'll increase the average seek distance whenever the head does
have to move between WAL and everything-else-in-the-database.

			regards, tom lane