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@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
