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

From Andres Freund
Subject Re: monitoring usage count distribution
Date
Msg-id 20230405190921.ck7v4y2h3ogoanvg@awork3.anarazel.de
Whole thread Raw
In response to Re: monitoring usage count distribution  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: monitoring usage count distribution
List pgsql-hackers
Hi,

On 2023-04-05 15:00:20 -0400, Robert Haas wrote:
> On Wed, Apr 5, 2023 at 1:51 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
> > On Wed, Apr 05, 2023 at 09:44:58AM -0400, Robert Haas wrote:
> > > On Tue, Apr 4, 2023 at 7:29 PM Andres Freund <andres@anarazel.de> wrote:
> > >> > 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'd have no issue with that.
> > >
> > > Cool.
> >
> > The six-element array approach won't show the number of dirty and pinned
> > buffers for each usage count, but I'm not sure that's a deal-breaker.
> > Barring objections, I'll post an updated patch shortly with that approach.
> 
> Right, well, I would personally be OK with 6 rows too, but I don't
> know what other people want.  I think either this or that is better
> than average.

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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: monitoring usage count distribution
Next
From: Melanie Plageman
Date:
Subject: Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode