Horton

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

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

View thread View on postgr.es
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: m.sakrejda@gmail.com
Cc: andres@anarazel.de, melanieplageman@gmail.com, vignesh21@gmail.com, pryzby@telsasoft.com, lukas@fittl.com, alvherre@alvh.no-ip.org, magnus@hagander.net, pgsql-hackers@postgresql.org, thomas.munro@gmail.com
Date: 2023-02-15T07:40:21Z
Lists: pgsql-hackers 
At Tue, 14 Feb 2023 22:35:01 -0800, Maciek Sakrejda <m.sakrejda@gmail.com> wrote in 
> On Tue, Feb 14, 2023 at 11:08 AM Andres Freund <andres@anarazel.de> wrote:
> > One thing I started to wonder about since is whether we should remove the io_
> > prefix from io_object, io_context. The prefixes make sense on the C level, but
> > it's not clear to me that that's also the case on the table level.
> 
> Yeah, +1. It's hard to argue that there would be any confusion,
> considering `io_` is in the name of the view.

We usually add such prefixes to the columns of system views and
catalogs, but it seems that's not the case for the stats views. Thus
+1 from me, too.

> (Unless, I suppose, some other, non-I/O, "some_object" or
> "some_context" column were to be introduced to this view in the
> future. But that doesn't seem likely?)

I don't think that can happen. As for corss-views ambiguity, that is
already present. Many columns in stats views share the same names with
some other views.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Commits

  1. Stabilize pg_stat_io writes test

  2. Fix flakey pg_stat_io test

  3. Suppress more compiler warnings in new pgstats code.

  4. Suppress compiler warnings in new pgstats code.

  5. Add tests for pg_stat_io

  6. Create regress_tblspc in test_setup

  7. Add pg_stat_io view, providing more detailed IO statistics

  8. pgstat: Track more detailed relation IO statistics

  9. pgstat: Infrastructure for more detailed IO statistics

  10. doc: Fix some issues in logical replication section

  11. Manual cleanup and pgindent of pgstat and bufmgr related code

  12. Have the planner consider Incremental Sort for DISTINCT

  13. Use actual backend IDs in pg_stat_get_backend_idset() and friends.

  14. Remove redundant call to pgstat_report_wal()

  15. Add BackendType for standalone backends

  16. Initialize backend status reporting during bootstrap.