Re: monitoring usage count distribution
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org,
schneider@ardentperf.com
Date: 2023-04-06T17:32:35Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Apr 5, 2023 at 4:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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. There seems to be enough support for the existing summary function definition to leave it as-is; Andres likes it for one, and I'm not excited about trying to persuade him he's wrong. But a second slightly-less-aggregated summary function is clearly useful as well. So I'm now thinking that we do want the patch as-submitted. (Caveat: I've not read the patch, just the description.) regards, tom lane
Commits
-
Add pg_buffercache_usage_counts() to contrib/pg_buffercache.
- f3fa31327ecb 16.0 landed