Re: Postgresql Performance on an HP DL385 and

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

In response to

Responses

Browse pgsql-performance by date

  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