From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SLRU statistics |
Date: | 2020-01-20 16:37:54 |
Message-ID: | 20200120163754.mbbkbhzaummlo47c@development |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 20, 2020 at 01:04:33AM +0000, tsunakawa(dot)takay(at)fujitsu(dot)com wrote:
>From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-01-20 16:44:20 | Re: [HACKERS] kqueue |
Previous Message | 曾文旌 (义从) | 2020-01-20 16:27:17 | Re: [Proposal] Global temporary tables |