Re: monitoring usage count distribution

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, schneider(at)ardentperf(dot)com
Subject: Re: monitoring usage count distribution
Date: 2023-04-05 19:09:21
Message-ID: 20230405190921.ck7v4y2h3ogoanvg@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmail(dot)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(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2023-04-05 19:25:52 Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode
Previous Message Tom Lane 2023-04-05 19:07:10 Re: monitoring usage count distribution