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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: m(dot)sakrejda(at)gmail(dot)com
Cc: andres(at)anarazel(dot)de, melanieplageman(at)gmail(dot)com, vignesh21(at)gmail(dot)com, pryzby(at)telsasoft(dot)com, lukas(at)fittl(dot)com, alvherre(at)alvh(dot)no-ip(dot)org, magnus(at)hagander(dot)net, pgsql-hackers(at)postgresql(dot)org, thomas(dot)munro(at)gmail(dot)com
Subject: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Date: 2023-02-15 07:40:21
Message-ID: 20230215.164021.227543675435826022.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 14 Feb 2023 22:35:01 -0800, Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com> wrote in
> On Tue, Feb 14, 2023 at 11:08 AM Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Geier 2023-02-15 07:51:56 Re: pg_stat_statements and "IN" conditions
Previous Message Bharath Rupireddy 2023-02-15 07:30:00 Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?