On Mon, Jul 26, 2010 at 03:23:20PM -0600, Greg Spiegelberg wrote: > On Mon, Jul 26, 2010 at 1:45 PM, Greg Smith <greg@xxxxxxxxxxxxxxx> wrote: > > Yeb Havinga wrote: > >> I did some ext3,ext4,xfs,jfs and also ext2 tests on the just-in-memory > >> read/write test. (scale 300) No real winners or losers, though ext2 isn't > >> really faster and the manual need for fix (y) during boot makes it > >> impractical in its standard configuration. > >> > > > > That's what happens every time I try it too. The theoretical benefits of > > ext2 for hosting PostgreSQL just don't translate into significant > > performance increases on database oriented tests, certainly not ones that > > would justify the downside of having fsck issues come back again. Glad to > > see that holds true on this hardware too. > I know I'm talking development now but is there a case for a pg_xlog block > device to remove the file system overhead and guaranteeing your data is > written sequentially every time? For one I doubt that its a relevant enough efficiency loss in comparison with a significantly significantly complex implementation (for one you cant grow/shrink, for another you have to do more complex, hw-dependent things like rounding to hardware boundaries, page size etc to stay efficient) for another my experience is that at a relatively low point XlogInsert gets to be the bottleneck - so I don't see much point in improving at that low level (yet at least). Where I would like to do some hw dependent measuring (because I see significant improvements there) would be prefetching for seqscan, indexscans et al. using blktrace... But I currently dont have the time. And its another topic ;-) Andres -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
