Josh Berkus <josh@agliodbs.com> writes: > Bruce, >> Did you test with full_page_writes on and off?
> I didn't use your full_page_writes version because Tom said it was > problematic. This is CVS from July 3rd. We already know the results: should be equivalent to the hack Josh tried first. So what we know at this point is that dumping full pages into WAL is expensive, and that the CRC calculation cost is not the main expense. (I suppose that this indicates the reduction to 32-bit CRC was helpful, because previous measurements sure suggested that CRC costs were important ...) What we still don't know is exactly where the main expense *is*. Is it I/O, WAL buffer lock contention, or what? I think the next step is to vary the WAL-related parameters (wal_buffers, wal_sync_method, and fsync) and see if we can learn anything that way. It's entirely plausible that the optimal values for those have changed due to our recent hacking. (Note: turning off fsync is of course not a production option, but it would be helpful to try it here --- it should give us a reading on whether disk I/O wait is the culprit or not.) I'd recommend that you *not* update to CVS tip, as that wouldn't accomplish much except call into question any comparisons to the runs you've already done. There are a number of unrelated changes this month that could have side-effects on performance. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster