Re: [PATCH] Add features to pg_stat_statements

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.

In response to

Responses

Browse pgsql-hackers by date

  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