Re: Wrong docs on wal_buffers?

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Wrong docs on wal_buffers?
Дата
Msg-id 4D269899.6040901@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Wrong docs on wal_buffers?  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Wrong docs on wal_buffers?  (Samuel Gendler <sgendler@ideasculptor.com>)
Список pgsql-performance
Josh Berkus wrote:
> We talked about bumping it to 512kB or 1MB for 9.1.  Did that get in?
> Do I need to write that patch?
>

If it defaulted to 3% of shared_buffers, min 64K & max 16MB for the auto
setting, it would for the most part become an autotuned parameter.  That
would make it 0.75 to 1MB at the standard anemic Linux default kernel
parameters.  Maybe more than some would like, but dropping
shared_buffers from 24MB to 23MB to keep this from being ridiculously
undersized is probably a win.  That percentage would reach 16MB by the
time shared_buffers was increased to 533MB, which also seems about right
to me.  On a really bad setup (brief pause to flip off Apple) with only
4MB to work with total, you'd end up with wal_buffers between 64 and
128K, so very close to the status quo.

Code that up, and we could probably even remove the parameter as a
tunable altogether.  Very few would see a downside relative to any
sensible configuration under the current situation, and many people
would notice better automagic performance with one less parameter to
tweak.  Given the recent investigations about the serious downsides of
tiny wal_buffers values on new Linux kernels when using open_datasync, a
touch more aggression about this setting seems particularly appropriate
to consider now.  That's been swapped out as the default, but it's still
possible people will switch to it.

--
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


В списке pgsql-performance по дате отправления:

Предыдущее
От: Mladen Gogala
Дата:
Сообщение: Re: "SELECT .. WHERE NOT IN" query running for hours
Следующее
От: "marc.hsiao"
Дата:
Сообщение: Re: How to turn autovacuum prevent wrap around run faster?