Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
От | Andres Freund |
---|---|
Тема | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) |
Дата | |
Msg-id | 20221228235613.ep47flalmnkqgnu7@awork3.anarazel.de обсуждение исходный текст |
Ответ на | 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 |
Hi, On 2022-10-06 13:42:09 -0400, Melanie Plageman wrote: > > Additionally, some minor notes: > > > > - Since the stats are counting blocks, it would make sense to prefix the view columns with "blks_", and word them inthe past tense (to match current style), i.e. "blks_written", "blks_read", "blks_extended", "blks_fsynced" (realisticallyone would combine this new view with other data e.g. from pg_stat_database or pg_stat_statements, which alluse the "blks_" prefix, and stop using pg_stat_bgwriter for this which does not use such a prefix) > > I have changed the column names to be in the past tense. For a while I was convinced by the consistency argument (after Melanie pointing it out to me). But the more I look, the less convinced I am. The existing IO related stats in pg_stat_database, pg_stat_bgwriter aren't past tense, just the ones in pg_stat_statements. pg_stat_database uses past tense for tup_*, but not xact_*, deadlocks, checksum_failures etc. And even pg_stat_statements isn't consistent about it - otherwise it'd be 'planned' instead of 'plans', 'called' instead of 'calls' etc. I started to look at the naming "tense" issue again, after I got "confused" about "extended", because that somehow makes me think about more detailed stats or such, rather than files getting extended. ISTM that 'evictions', 'extends', 'fsyncs', 'reads', 'reuses', 'writes' are clearer than the past tense versions, and about as consistent with existing columns. FWIW, I've been hacking on this code a bunch, mostly around renaming things and changing the 'stacking' of the patches. My current state is at https://github.com/anarazel/postgres/tree/pg_stat_io A bit more to do before posting the edited version... Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: