Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
От | Alvaro Herrera |
---|---|
Тема | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) |
Дата | |
Msg-id | 202106042152.ny3a4fqoefx7@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
|
Список | pgsql-hackers |
On 2021-Apr-12, Melanie Plageman wrote: > As for the way I have recorded strategy writes -- it is quite inelegant, > but, I wanted to make sure that I only counted a strategy write as one > in which the backend wrote out the dirty buffer from its strategy ring > but did not check if there was any clean buffer in shared buffers more > generally (so, it is *potentially* an avoidable write). I'm not sure if > this distinction is useful to anyone. I haven't done enough with > BufferAccessStrategies to know what I'd want to know about them when > developing or using Postgres. However, if I don't need to be so careful, > it will make the code much simpler (though, I'm sure I can improve the > code regardless). I was bitten last year by REFRESH MATERIALIZED VIEW counting its writes via buffers_backend, and I was very surprised/confused about it. So it seems definitely worthwhile to count writes via strategy separately. For a DBA tuning the server configuration it is very useful. The main thing is to *not* let these writes end up regular buffers_backend (or whatever you call these now). I didn't read your patch, but the way you have described it seems okay to me. -- Álvaro Herrera 39°49'30"S 73°17'W
В списке pgsql-hackers по дате отправления: