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

On Wed, Oct 19, 2022 at 12:27 PM Melanie Plageman
<melanieplageman(at)gmail(dot)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"

>+ 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?

>+ <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.

>+ future with a new shared buffer. A high number of
>+ <literal>bulkread</literal> rejections can indicate a need for more
>+ frequent vacuuming or more aggressive autovacuum settings, as buffers are
>+ dirtied during a bulkread operation when updating the hint bit or when
>+ performing on-access pruning.

This is great. Just wanted to re-iterate that notes like this are
really helpful to understanding this view.

> 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...