Re: [PATCH] pg_stat_statements dealloc field ignores manual deallocation
От | Julien Rouhaud |
---|---|
Тема | Re: [PATCH] pg_stat_statements dealloc field ignores manual deallocation |
Дата | |
Msg-id | 20210319141544.kkg4s4ay2d4mtaum@nol обсуждение исходный текст |
Ответ на | [PATCH] pg_stat_statements dealloc field ignores manual deallocation (Андрей Зубков <zubkov@moonset.ru>) |
Ответы |
Re: [PATCH] pg_stat_statements dealloc field ignores manual deallocation
|
Список | 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.
В списке pgsql-hackers по дате отправления: