Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)

Поиск
Список
Период
Сортировка
От Melanie Plageman
Тема Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Дата
Msg-id CAAKRu_b3rSOr33A6HGKN747QxpB0UkgGfjhhbn9eaEcp24HyhQ@mail.gmail.com
обсуждение исходный текст
Ответ на 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?)  (Melanie Plageman <melanieplageman@gmail.com>)
Список pgsql-hackers
On Mon, Jan 2, 2023 at 8:15 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> On Mon, Jan 2, 2023 at 5:46 PM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
> >
> > Besides docs, there is one large change to the code which I am currently
> > working on, which is to change PgStat_IOOpCounters into an array of
> > PgStatCounters instead of having individual members for each IOOp type.
> > I hadn't done this previously because the additional level of nesting
> > seemed confusing. However, it seems it would simplify the code quite a
> > bit and is probably worth doing.
>
> As described above, attached v43 uses an array for the PgStatCounters of
> IOOps instead of struct members.

This wasn't quite a multi-dimensional array. Attached is v44, in which I
have removed all of the granular struct types -- PgStat_IOOps,
PgStat_IOContext, and PgStat_IOObject by collapsing them into a single
array of PgStat_Counters in a new struct PgStat_BackendIO. I needed to
keep this in addition to PgStat_IO to have a data type for backends to
track their stats in locally.

I've also done another round of cleanup.

- Melanie

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: CI and test improvements