Date: Tue, 06 Dec 2005 20:31:07 -0500
From: Michael Stone <mstone+postgres@mathom.us>
Subject: Re: LVM and Postgres
In-reply-to: <33c6269f0512061652u73a690t8af8a276118b1a83@mail.gmail.com>
To: Alex Turner <armtuk@gmail.com>
Cc: pgsql-performance@postgresql.org
Mail-followup-to: Alex Turner <armtuk@gmail.com>,
	pgsql-performance@postgresql.org
Message-id: <20051207013107.GP7330@mathom.us>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
References: <20051206093818.GE6708@campbell-lange.net>
	<dn4rb3$2d55$1@news.hub.org>
	<20051206213623.GD14427@campbell-lange.net>
	<20051207002537.GN7330@mathom.us>
	<33c6269f0512061652u73a690t8af8a276118b1a83@mail.gmail.com>
User-Agent: Mutt/1.5.11

On Tue, Dec 06, 2005 at 07:52:25PM -0500, Alex Turner wrote:
>I would argue that almost certainly won't by doing that as you will
>create a new place even further away for the disk head to seek to
>instead of just another file on the same FS that is probably closer to
>the current head position.

I would argue that you should benchmark it instead of speculating. You
are perhaps underestimating the effect of the xfs log. (Ordinarily xfs
has great performance, but it seems to be fairly lousy at
fsync/osync/etc operations in my benchmarks; my wild speculation is that
the sync forces a log flush.) At any rate you're going to have a lot of
head movement on any reasonably sized filesystem anyway, and I'm not
convinced that hoping that your data will happen to land close to your log is
a valid, repeatable optimization technique. Note that the WAL will
wander around the disk as files are created and deleted, whereas tables
are basically updated in place.

Mike Stone