Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) - Mailing list pgsql-hackers

On Sun, Oct 23, 2022 at 6:35 PM Maciek Sakrejda <m.sakrejda@gmail.com> wrote:
>
> On Wed, Oct 19, 2022 at 12:27 PM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
> >
> > v34 is attached.
> > I think the column names need discussion. Also, the docs need more work
> > (I added a lot of new content there). I could use feedback on the column
> > names and definitions and review/rephrasing ideas for the docs
> > additions.
>
> Nice! I think the expanded docs are great, and make this information
> much easier to interpret.
>
> >+       <varname>io_context</varname> <literal>bulkread</literal>, existing
> >+       dirty buffers in the ring requirng flush are
>
> "requiring"

Thanks!

>
> >+       shared buffers were acquired from the freelist and added to the
> >+       fixed-size strategy ring buffer. Shared buffers are added to the
> >+       strategy ring lazily. If the current buffer in the ring is pinned or in
>
> This is the first mention of the term "strategy" in these docs. It's
> not totally opaque, since there's some context, but maybe we should
> either try to avoid that term or define it more explicitly?
>

I am thinking it might be good to define the term strategy for use in
this view documentation.
In the IOContext column documentation, I've added this
...
    avoid occupying an undue portion of the main shared buffer pool. This
    pattern is called a Buffer Access Strategy and the fixed-size ring
    buffer can be referred to as a <quote>strategy ring buffer</quote>.
</para></entry>

I was thinking this would allow me to refer to the strategy ring buffer
more easily. I fear simply referring to "the" ring buffer throughout
this view documentation will be confusing.

> >+       <varname>io_context</varname>s. This is equivalent to
> >+       <varname>evicted</varname> for shared buffers in
> >+       <varname>io_context</varname> <literal>shared</literal>, as the contents
> >+       of the buffer are <quote>evicted</quote> but refers to the case when the
>
> I don't quite follow this: does this mean that I should expect
> 'reused' and 'evicted' to be equal in the 'shared' context, because
> they represent the same thing? Or will 'reused' just be null because
> it's not distinct from 'evicted'? It looks like it's null right now,
> but I find the wording here confusing.

You should only see evictions when the strategy evicts shared buffers
and reuses when the strategy evicts existing strategy buffers.

How about this instead in this docs?

the number of times an existing buffer in the strategy ring was reused
as part of an operation in the <literal>bulkread</literal>,
<literal>bulkwrite</literal>, or <literal>vacuum</literal>
<varname>io_context</varname>s. when a buffer access strategy
<quote>reuses</quote> a buffer in the strategy ring, it must evict its
contents, incrementing <varname>reused</varname>. when a buffer access
strategy adds a new shared buffer to the strategy ring and this shared
buffer is occupied, the buffer access strategy must evict the contents
of the shared buffer, incrementing <varname>evicted</varname>.


> > I've implemented a change using the same function pg_settings uses to
> > turn the build-time parameter BLCKSZ into 8kB (get_config_unit_name())
> > using the flag GUC_UNIT_BLOCKS. I am unsure if this is better or worse
> > than "block_size". I am feeling very conflicted about this column.
>
> Yeah, I guess it feels less natural here than in pg_settings, but it
> still kind of feels like one way of doing this is better than two...

So, Andres pointed out that it would be nice to be able to multiply the
unit column by the operation column (e.g. select unit * reused from
pg_stat_io...) and get a number of bytes. Then you can use
pg_size_pretty to convert it to something more human readable.

It probably shouldn't be called unit, then, since that would be the same
name as pg_settings but a different meaning. I thought of
"bytes_conversion". Then, non-block-oriented IO also wouldn't have to be
in bytes. They could put 1000 or 10000 for bytes_conversion.

What do you think?

- Melanie