Re: Postgresql Performance on an HP DL385 and

On Mon, Aug 14, 2006 at 01:03:41PM -0400, Michael Stone wrote:
> 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. :)

Well, I'm not digging hard numbers out either, so that's fair. :) But it
would be very handy if people posted results from any testing they're
doing as part of setting up new hardware. Actually, a wiki would
probably be ideal for this...

> >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.

Certainly... my contention is that if you have a good controller that's
caching writes then drive layout basically won't matter at all, because
the controller will just magically make things optimal.

> 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.

Well, if the controller is caching with a BBU, I'm not sure that order
matters anymore, because the controller should be able to re-order at
will. Theoretically. :) But this is why having some actual data posted
somewhere would be great.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461