"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> I've just spent the last day and a half trying to benchmark our new database
> installation to find a good value for wal_buffers. The quick answer - there
> isn't, just leave it on the default of 8.
I don't think this is based on a useful test for wal_buffers. The
wal_buffers setting only has to be large enough for the maximum amount
of WAL log data that your system emits between commits, because a commit
(from anyone) is going to flush the WAL data to disk (for everyone).
So a benchmark based on short transactions is just not going to show
any benefit to increasing the setting.
Benchmarking, say, the speed of massive COPY IN operations might show
some advantage to larger wal_buffers. Although I'm not real sure that
it'll make any difference for any single-backend test. It's really just
the case where you have concurrent transactions that all make lots of
updates before committing that's likely to show a win.
> One proof that has come out of this is that wal_buffers does not affect
> SELECT only performance in any way.
Coulda told you that without testing ;-). Read-only transactions emit
no WAL entries.
regards, tom lane