Re: [PATCH] Add features to pg_stat_statements - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: [PATCH] Add features to pg_stat_statements
Date
Msg-id CAOBaU_bV8K29DEimA_+VNHd=0kPghxzQpepyhn=WAzJh6CL7ag@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Add features to pg_stat_statements  (Katsuragi Yuta <btkatsuragiyu@oss.nttdata.com>)
Responses Re: [PATCH] Add features to pg_stat_statements  (Katsuragi Yuta <btkatsuragiyu@oss.nttdata.com>)
List pgsql-hackers
On Wed, Sep 23, 2020 at 2:48 PM Katsuragi Yuta
<btkatsuragiyu@oss.nttdata.com> wrote:
>
> On 2020-09-18 18:49, Julien Rouhaud wrote:
> > Did you consider also adding the cumulated number of
> > evicted entries?  This could be useful to know how to configure
> > pg_stat_statements.max.
>
> Thank you for your comments!
> I overlooked the cumulated number of evicted entries.
> This statistic looks important. But, I am not sure
> if I should add this statistic to a view.
> This is because I am not sure how to utilize the cumulated
> number of evicted entries for configuring pg_stat_statements.max.

You're right, as the number of evicted entries isn't depending on the
number of entries that wouls been needed to contain the entirely
workload.

> Not only providing a view but also logging evictions
> along with the number of evicted entries might be a choice.
> This idea is from legrand legrand [1].

+1.  I'm wondering if logging each evicted entry, with its queryid,
would help to estimate the actual size of the normalised queries set.



pgsql-hackers by date:

Previous
From: Katsuragi Yuta
Date:
Subject: Re: [PATCH] Add features to pg_stat_statements
Next
From: Keisuke Kuroda
Date:
Subject: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables