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