[PATCH] pg_stat_statements dealloc field ignores manual deallocation

From: Андрей Зубков <zubkov(at)moonset(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: [PATCH] pg_stat_statements dealloc field ignores manual deallocation
Date: 2021-03-19 14:08:45
Message-ID: 9fc0ff02b9b6f12e92657e594d32c997aa8a13cb.camel@moonset.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

This is a proposal of a patch for pg_stat_statements extension. It
corrects deallocation events accounting.

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, 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.

Let's see how it happens:

postgres=# select pg_stat_statements_reset();
postgres=# select 1;
?column?
----------
1
(1 row)
postgres=# select dealloc from pg_stat_statements_info ;
dealloc
---------
0
(1 row)

postgres=# select pg_stat_statements_reset(userid,dbid,queryid)
postgres-# from pg_stat_statements where query = 'select $1';
pg_stat_statements_reset
--------------------------

(1 row)

postgres=# select dealloc from pg_stat_statements_info ;
dealloc
---------
0 -- Here must be a one now, as deallocation happened
(1 row)

This patch adds accounting of manual deallocation events.

--
Andrei Zubkov
Postgres Professional
The Russian Postgres Company

Attachment Content-Type Size
pg_stat_statements_dealloc_fix_patch_2021_0319.patch text/x-patch 762 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2021-03-19 14:09:45 Re: support for MERGE
Previous Message Tom Lane 2021-03-19 14:00:14 Re: Allow an alias to be attached directly to a JOIN ... USING