> And the risks are rather asymmetric. I don't know of any problem from
> too large a buffer until it starts crowding out shared_buffers, while
> under-sizing leads to the rather drastic performance consequences of
> AdvanceXLInsertBuffer having to wait on the WALWriteLock while holding
> the WALInsertLock,
Yes, performance testing has bourne that out. Increasing wal_buffers to
between 1MB and 16MB has benfitted most test cases (DBT2, pgBench, user
databases) substantially, while an increase has never been shown to be a
penalty. Increases above 16MB didn't seem to help, which is
unsurprising given the size of a WAL segment.
> But I wonder if initdb.c, when selecting the default shared_buffers,
> shouldn't test with wal_buffers = shared_buffers/64 or
> shared_buffers/128, with a lower limit of 8 blocks, and set that as
> the default.
We talked about bumping it to 512kB or 1MB for 9.1. Did that get in?
Do I need to write that patch?
It would be nice to have it default to 16MB out of the gate, but there
we're up against the Linux/FreeBSD SysV memory limits again. When are
those OSes going to modernize?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
