Re: Introduce a new view for checkpointer related stats
От | Michael Paquier |
---|---|
Тема | Re: Introduce a new view for checkpointer related stats |
Дата | |
Msg-id | ZTshY4g1SAEyXfLE@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Introduce a new view for checkpointer related stats (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Introduce a new view for checkpointer related stats
|
Список | pgsql-hackers |
On Thu, Oct 26, 2023 at 10:55:00PM +0530, Bharath Rupireddy wrote: > On Thu, Oct 26, 2023 at 7:30 AM Michael Paquier <michael@paquier.xyz> wrote: >> Why is that in 0002? Isn't that something we should treat as a bug >> fix of its own, even backpatching it to make sure that the flush >> requests for individual commit_ts, multixact and clog files are >> counted in the stats? > > +1. I included the fix in a separate patch 0002 here. Hmm. As per the existing call of pgstat_count_slru_flush() in SimpleLruWriteAll(), routine called SimpleLruFlush() until ~13 and dee663f78439, an incrementation of 1 for slru_stats_idx refers to all the flushes for all the dirty data of this SLRU in a single pass. This addition actually means that we would now increment the counter for each sync request, changing its meaning. Perhaps there is an argument for changing the meaning of this parameter to be based on the number of flush requests completed, but if that were to happen it would be better to remove pgstat_count_slru_flush() in SimpleLruWriteAll(), I guess, or just aggregate this counter once, which would be cheaper. >> Saying that, I am OK with moving ahead with 0001 and 0002 to remove >> buffers_backend_fsync and buffers_backend from pg_stat_bgwriter, but >> it is better to merge them into a single commit. It helps with 0003 >> and this would encourage the use of pg_stat_io that does a better job >> overall with more field granularity. > > I merged v8 0001 and 0002 into one single patch, PSA v9-0001. v9-0001 is OK, so I have applied it. v9-0003 is mostly a mechanical change, and it passes the eye test. I have spotted two nits. +CREATE VIEW pg_stat_checkpointer AS + SELECT + pg_stat_get_checkpointer_num_timed() AS num_timed, + pg_stat_get_checkpointer_num_requested() AS num_requested, + pg_stat_get_checkpointer_write_time() AS write_time, + pg_stat_get_checkpointer_sync_time() AS sync_time, + pg_stat_get_checkpointer_buffers_written() AS buffers_written, + pg_stat_get_checkpointer_stat_reset_time() AS stats_reset; Okay with this layer. I am wondering if others have opinions to share about these names for the attributes of pg_stat_checkpointer, though. - single row, containing global data for the cluster. + single row, containing data about the bgwriter of the cluster. "bgwriter" is used in one place of the docs, so perhaps "background writer" is better here? The error message generated for an incorrect target needs to be updated in pg_stat_reset_shared(): =# select pg_stat_reset_shared('checkpointe'); ERROR: 22023: unrecognized reset target: "checkpointe" HINT: Target must be "archiver", "bgwriter", "io", "recovery_prefetch", or "wal". -- Michael
Вложения
В списке pgsql-hackers по дате отправления: