From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Katsuragi Yuta <btkatsuragiyu(at)oss(dot)nttdata(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Add features to pg_stat_statements |
Date: | 2020-09-23 07:01:12 |
Message-ID: | CAOBaU_bV8K29DEimA_+VNHd=0kPghxzQpepyhn=WAzJh6CL7ag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 23, 2020 at 2:48 PM Katsuragi Yuta
<btkatsuragiyu(at)oss(dot)nttdata(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Keisuke Kuroda | 2020-09-23 07:39:15 | Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables |
Previous Message | Katsuragi Yuta | 2020-09-23 06:48:15 | Re: [PATCH] Add features to pg_stat_statements |