Re: monitoring usage count distribution
Melanie Plageman <melanieplageman@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@postgresql.org, schneider@ardentperf.com, Andres Freund <andres@anarazel.de>, Melih Mutlu <m.melihmutlu@gmail.com>,
smilingsamay@gmail.com
Date: 2023-04-04T23:10:24Z
Lists: 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
Commits
-
Add pg_buffercache_usage_counts() to contrib/pg_buffercache.
- f3fa31327ecb 16.0 landed