Re: monitoring usage count distribution - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: monitoring usage count distribution
Date
Msg-id CAAKRu_bvV2_apXjDZ0bw8Ljqx0eN5=hPAn35fYPZq6j6K0ftFQ@mail.gmail.com
Whole thread Raw
In response to Re: monitoring usage count distribution  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Apr 4, 2023 at 2:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Jan 30, 2023 at 6:30 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
> >> My colleague Jeremy Schneider (CC'd) was recently looking into usage count
> >> distributions for various workloads, and he mentioned that it would be nice
> >> to have an easy way to do $SUBJECT.
>
> > I'm skeptical that pg_buffercache_summary() is a good idea at all, but
> > having it display the average usage count seems like a particularly
> > poor idea. That information is almost meaningless. Replacing that with
> > a six-element integer array would be a clear improvement and, IMHO,
> > better than adding yet another function to the extension.
>
> I had not realized that pg_buffercache_summary() is new in v16,
> but since it is, we still have time to rethink its definition.
> +1 for de-aggregating --- I agree that the overall average is
> unlikely to have much value.

So, I have used pg_buffercache_summary() to give me a high-level idea of
the usage count when I am benchmarking a particular workload -- and I
would have found it harder to look at 6 rows instead of 1. That being
said, having six rows is more versatile as you could aggregate it
yourself easily.

- Melanie



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Next
From: Kirk Wolak
Date:
Subject: Re: psql \watch 2nd argument: iteration count