If you are using ext3, your performance on the RAID card may also improve if the postgres xlog is not on the same partition as the data. Otherwise, for every transaction commit, all of the data on the whole partition will have to be sync()'d not just the xlog.
Also, what is the performance difference between all the inserts in one script if you do: * all your statements in the script vs. * first line is "BEGIN;" then all your statements, then "COMMIT;" at the end? If these two are about the same on your old IDE drive, then your I/O stack (file system + OS + hardware) is lying to you about fsync(). The latter should be a lot faster on your RAID card if write-back caching is not on. On Jul 19, 2010, at 12:53 PM, Daniel Ferreira de Lima wrote: That said, a look into the write-caching+BBU policy on your controller is worthwhile. If you're running this application successfully on some hardware but not others, that could be a source for the difference. I think it's really a BBU/BBWC problem. The tests that we made in the lab with HP Blade G5 (G6 doesn't support kernel version 2.4) turning the battery off show us the 'same' performance of the "pizza-box" HP DL 380 G5.. an old joke. 40 secs to 2000 insertions: like a chariot. We're finding the cache expansion and batteries (and.. why it's not default???). I think that this thread is now finished. Thanks! -- Daniel Ferreira
