Re: minimizing pg_stat_statements performance overhead

Robert Haas wrote
> On Tue, Apr 2, 2019 at 5:37 AM Christoph Berg <

> myon@

> > wrote:
>> Re: Raymond Martin 2019-04-01 <

> BN8PR21MB121708579A3782866DF1F745B1550(at)(dot)outlook

> >
>> > Thanks again Fabien. I am attaching the patch to this email in the hope
>> of getting it approved during the next commit fest.
>>
>> you sent the patch as UTF-16, could you re-send it as plain ascii?
>
> One thing that needs some thought here is what happens if the value of
> pgss_enabled() changes. For example we don't want a situation where
> if the value changes from off to on between one stage of processing
> and another, the server crashes.
>
> I don't know whether that's a risk here or not; it's just something to
> think about.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

Hi, here is a simple test where I commented that line
in pgss_post_parse_analyze
to force return; (as if pgss_enabled() was disabled)
but kept pgss_enabled() every where else

/* Safety check... */
// if (!pgss || !pgss_hash || !pgss_enabled())
return;

This works without crash as you can see here after:

postgres=# select pg_stat_statements_reset();
pg_stat_statements_reset
--------------------------

(1 row)

postgres=# show pg_stat_statements.track;
pg_stat_statements.track
--------------------------
all
(1 row)

postgres=# create table a(id int);
CREATE TABLE

postgres=# select * from a where id=1;
id
----
(0 rows)

postgres=# select queryid,query,calls from pg_stat_statements;
queryid | query | calls
---------------------+-------------------------------+-------
1033669194118974675 | show pg_stat_statements.track | 1
3022461129400094363 | create table a(id int) | 1
(2 rows)

regards
PAscal

--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html