Re: per backend WAL statistics

Поиск
Список
Период
Сортировка
Искать
От
Bertrand Drouvot
Тема
Re: per backend WAL statistics
Дата
Msg-id
Z6HUpWt11kZNHey0@ip-10-97-1-34.eu-west-3.compute.internal
Ответ на
Список
Дерево обсуждения
Re: per backend WAL statistics Tom Lane <tgl@sss.pgh.pa.us>
Re: per backend WAL statistics Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: per backend WAL statistics Michael Paquier <michael@paquier.xyz>
Hi,

On Thu, Jan 23, 2025 at 09:57:50AM +0000, Bertrand Drouvot wrote:
> On Thu, Jan 23, 2025 at 05:05:30PM +0900, Michael Paquier wrote:
> > As far I got it from a code
> > read, prevWalUsage, prevBackendWalUsage and their local trackings in
> > pgstat_backend.c and pgstat_wal.c rely on instrument.c as the primary
> > source, as pgWalUsage can never be reset.  Is that right?
> 
> yeah, IIUC pgWalUsage acts as the primary source that both prevWalUsage and
> prevBackendWalUsage diff against to calculate incremental stats.
> 

Now that a051e71e28a is in, I think that we can reduce the scope of this patch
(i.e reduce the number of stats provided by pg_stat_get_backend_wal()).

I think we can keep:

wal_records
wal_fpi 
wal_bytes (because it differs from write_bytes in pg_stat_get_backend_io())
wal_buffers_full

The first 3 are in the WalUsage struct.

I think that: 

wal_write (and wal_write_time)
wal_sync (and wal_sync_time)

can be extracted from pg_stat_get_backend_io(), so there is no need to duplicate
this information. The same comment could be done for pg_stat_wal and pg_stat_io
though, but pg_stat_wal already exists so removing fields has not the same
effect.

What are you thoughts about keeping in pg_stat_get_backend_wal() only the
4 stats mentioned above?

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com


В списке pgsql-hackers по дате отправления
От: Masahiko Sawada
Дата:
От: Masahiko Sawada
Дата:
FAQ