Thanks for the info.
I managed to pull out some archived posts to this list from the PostgreSQL
web site about this issue which have helped a bit.
Unfortunatly, the FS has been chosen before considering the impact of it on
I/O for PostgreSQL. As the Cluster is sitting on it's on 200GB IDE drive for
the moment and the system is partially live, it's not feasable to change the
underlying file system without great pain and suffering.
In the great fsync debates that I've seen, the pervasive opinion about
journalling file systems under Linux and PostgreSQL is to have the
filesystem mount option data=writeback, assuming that fsync in PostgreSQL
will handle coherency of the file data and the FS will handle metadata.
This is all academic to a point, as tuning the FS will get a small
improvement on I/O compared to the improvement potential of moving to
SCSI/FCAL, that and getting more memory.
Regards,
Pete de Zwart.
Christopher Browne [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Your understanding of the impact of filesystem journalling isn't
entirely correct. In the cases of interest, journalling is done on
metadata, not on the contents of files, with the result that there
isn't really that much overlap between the two forms of journalling
that are taking place.
I did some benchmarking last year that compared, on a write-heavy
load, ext3, XFS, and JFS.
I found that ext3 was materially (if memory serves, 15%) slower than
the others, and that there was a persistent _slight_ (a couple
percent) advantage to JFS over XFS.
This _isn't_ highly material, particularly considering that I was
working with a 100% Write load, whereas real world work is likely to
have more of a mixture.
If you have reason to consider one filesystem or another better
supported by your distribution vendor, THAT is a much more important
reason to pick a particular filesystem than 'raw speed.'
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
