Re: SLRU statistics - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: SLRU statistics
Date
Msg-id 20200120163754.mbbkbhzaummlo47c@development
Whole thread Raw
In response to RE: SLRU statistics  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Responses Re: SLRU statistics  (Alvaro Herrera <alvherre@2ndquadrant.com>)
RE: SLRU statistics  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Re: SLRU statistics  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
List pgsql-hackers
On Mon, Jan 20, 2020 at 01:04:33AM +0000, tsunakawa.takay@fujitsu.com wrote:
>From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
>> One of the stats I occasionally wanted to know are stats for the SLRU
>> stats (we have couple of those - clog, subtrans, ...). So here is a WIP
>> version of a patch adding that.
>
>How can users take advantage of this information?  I think we also need
>the ability to set the size of SLRU buffers.  (I want to be freed from
>the concern about the buffer shortage by setting the buffer size to its
>maximum.  For example, CLOG would be only 1 GB.)
>

You're right the users can't really take advantage of this - my primary
motivation was providing a feedback for devs, benchmarking etc. That
might have been done with DEBUG messages or something, but this seems
more convenient.

I think it's unclear how desirable / necessary it is to allow users to
tweak those caches. I don't think we should have a GUC for everything,
but maybe there's some sort of heuristics to determine the size. The
assumption is we actually find practical workloads where the size of
these SLRUs is a performance issue.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: "曾文旌(义从)"
Date:
Subject: Re: [Proposal] Global temporary tables
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] kqueue