Re: bgwriter_flush_after

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: bgwriter_flush_after
Дата
Msg-id CAKFQuwY5UVEjPm8VX9bMeaQF-zRKn=d0QYCxtKa2wamFKshzCA@mail.gmail.com
обсуждение исходный текст
Ответ на bgwriter_flush_after  (Henry Francisco Garcia Cortez <garcortez@gmail.com>)
Ответы Re: bgwriter_flush_after  (Henry Francisco Garcia Cortez <garcortez@gmail.com>)
Список pgsql-admin
On Thursday, October 14, 2021, Henry Francisco Garcia Cortez <garcortez@gmail.com> wrote:
I was reading about bgwriter_flush_after I found this website https://postgreshelp.com/postgresql_shared_buffers/ however, I have some questions:
First the parameter bgwriter_flush_after is amount of pages that operating system’s cache could download to disk every time Fsync is called.
Second If I want to increase the parameter bgwriter_flush_after, for instance to 2MB Will I get a better performance? and
Finally, What will be the cons of increasing this parameter?


Pushing cache data to disk consumes I/O bandwidth.  If a page is updated it eventually has to be pushed to disk.  However, if it is updated again before that mandatory flush only the final version needs to be written.  By attempting to spread out the I/O there is a decreased chance for that efficiency to happen.  Instead, the first update gets flushed well before the mandatory time and then the second update also gets flushed.  Thus the total I/O consumed is double, though this is mitigated by the fact the time period considered is spread out.

The benefits are circumstantial, which basically means figure out you have a problem first then see whether this knob can help alleviate it.  Though I suppose there may be some useful guidelines to consider; I’m just not aware of them.

David J.

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

Предыдущее
От: Henry Francisco Garcia Cortez
Дата:
Сообщение: bgwriter_flush_after
Следующее
От: Sébastien Boutté
Дата:
Сообщение: Index Corrupted ?