Re: monitoring usage count distribution
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, schneider@ardentperf.com
Date: 2023-04-06T17:20:53Z
Lists: pgsql-hackers
On Wed, Apr 5, 2023 at 4:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Nathan Bossart <nathandbossart@gmail.com> writes: > > On Wed, Apr 05, 2023 at 12:09:21PM -0700, Andres Freund wrote: > >> I would not mind having a separate function returning 6 rows, if we really > >> want that, but making pg_buffercache_summary() return 6 rows would imo make it > >> less useful for getting a quick overview. At least I am not that quick summing > >> up multple rows, just to get a quick overview over the number of dirty rows. > > > This is what v1-0001 does. We could probably make pg_buffercache_summary a > > view on pg_buffercache_usage_counts, too, but that doesn't strike me as > > tremendously important. > > Having two functions doesn't seem unreasonable to me either. > Robert spoke against it to start with, does he still want to > advocate for that? My position is that if we replace the average usage count with something that gives a count for each usage count, that's a win. I don't have a strong opinion on an array vs. a result set vs. some other way of doing that. If we leave the average usage count in there and add yet another function to give the detail, I tend to think that's not a great plan, but I'll desist if everyone else thinks otherwise. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Add pg_buffercache_usage_counts() to contrib/pg_buffercache.
- f3fa31327ecb 16.0 landed