Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
От | Maciek Sakrejda |
---|---|
Тема | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) |
Дата | |
Msg-id | CAOtHd0BYqEWWDrEPiEvZn9gELU1fSknFtAODcCVKFbtcxOMkbA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) (Melanie Plageman <melanieplageman@gmail.com>) |
Список | pgsql-hackers |
On Tue, Jan 17, 2023 at 9:22 AM Melanie Plageman <melanieplageman@gmail.com> wrote: > On Mon, Jan 16, 2023 at 4:42 PM Maciek Sakrejda <m.sakrejda@gmail.com> wrote: > > I missed a couple of versions, but I think the docs are clearer now. > > I'm torn on losing some of the detail, but overall I do think it's a > > good trade-off. Moving some details out to after the table does keep > > the bulk of the view documentation more readable, and the "inform > > database tuning" part is great. I really like the idea of a separate > > Interpreting Statistics section, but for now this works. > > > > >+ <literal>vacuum</literal>: I/O operations performed outside of shared > > >+ buffers while vacuuming and analyzing permanent relations. > > > > Why only permanent relations? Are temporary relations treated > > differently? I imagine if someone has a temp-table-heavy workload that > > requires regularly vacuuming and analyzing those relations, this point > > may be confusing without some additional explanation. > > Ah, yes. This is a bit confusing. We don't use buffer access strategies > when operating on temp relations, so vacuuming them is counted in IO > Context normal. I've added this information to the docs but now that > definition is a bit long. Perhaps it should be a note? That seems like > it would draw too much attention to this detail, though... Thanks for clarifying. I think the updated definition still works: it's still shorter than the `normal` context definition.
В списке pgsql-hackers по дате отправления: