From: | Michael Stone <mstone+postgres(at)mathom(dot)us> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Postgresql Performance on an HP DL385 and |
Date: | 2006-08-14 17:03:41 |
Message-ID: | 20060814170338.GM2900@mathom.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Aug 14, 2006 at 10:38:41AM -0500, Jim C. Nasby wrote:
>Got any data to back that up?
yes. that I'm willing to dig out? no. :)
>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.
The pg_xlog files will tend to be created up at the front of the disk
and just sit there. Any affect the positioning has one way or the other
isn't going to be measurable/repeatable. With a write cache for pg_xlog
the positioning isn't really going to matter anyway, since you don't
have to wait for a seek to do the write.
From what I've observed in testing, I'd guess that the issue is that
certain filesystem operations (including, possibly, metadata operations)
are handled in order. If you have xlog on a seperate partition there
will never be anything competing with a log write on the server side,
which won't necessarily be true on a shared filesystem. Even if you have
a battery backed write cache, you might still have to wait a relatively
long time for the pg_xlog data to be written out if there's already a
lot of other stuff in a filesystem write queue.
Mike Stone
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-08-14 17:05:46 | Re: Postgresql Performance on an HP DL385 and |
Previous Message | Steve Poe | 2006-08-14 15:51:09 | Re: Postgresql Performance on an HP DL385 and |