Re: [PATCH] pg_stat_statements dealloc field ignores manual deallocation

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Андрей Зубков <zubkov(at)moonset(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] pg_stat_statements dealloc field ignores manual deallocation
Date: 2021-03-19 14:15:44
Message-ID: 20210319141544.kkg4s4ay2d4mtaum@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 19, 2021 at 05:08:45PM +0300, Андрей Зубков wrote:
>
> Since 2e0fedf there is a view pg_stat_statements_info is available in
> pg_stat_statements extension. It has a dealloc field, that should be a
> counter of deallocation events happened.
> Right now it accounts only automatic deallocation events, happened when
> we need a place for a new statement,

Yes, and that behavior is documented:

dealloc bigint

Total number of times pg_stat_statements entries about the least-executed
statements were deallocated because more distinct statements than
pg_stat_statements.max were observed

> but manual deallocation events
> caused by pg_stat_statements_reset() function for some subset of
> collected statements is not accounted.
> My opinion is that manual deallocation is a deallocation too and it
> must be accounted in dealloc field of pg_stat_statements_info view.

I disagree. The point of that field is to help users configuring
pg_stat_statements.max, as evictions have a huge overhead in many workloads.

If users remove entries for some reasons, we don't have to give the impression
that pg_stat_statements.max is too low and that it should be increased,
especially since it requires a restart.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2021-03-19 14:17:50 Re: cleanup temporary files after crash
Previous Message Dilip Kumar 2021-03-19 14:11:03 Re: [HACKERS] Custom compression methods