testing with pg_stat_statements - Mailing list pgsql-hackers

From Andrew Dunstan
Subject testing with pg_stat_statements
Date
Msg-id 5bcafdc5-a9cb-65eb-b110-1916c1d87f8a@dunslane.net
Whole thread Raw
Responses Re: testing with pg_stat_statements  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
After the recent case where the SQL/JSON patches had an error that only
exhibited when pg_stat_statement was preloaded, I decided to see if
there were any other such cases in our committed code. So I tested it
out with a modified buildfarm client with this line added in the initdb
step where it's adding the extra_config to postgresql.conf:

    print $handle "shared_preload_libraries = 'pg_stat_statements'\n";

The good news is that it didn't actually find anything amiss. The bad
news is that it generated a bunch of diffs along these lines:


 EXPLAIN (verbose, costs off) SELECT * FROM functest_sri1();
-              QUERY PLAN             
---------------------------------------
+              QUERY PLAN              
+---------------------------------------
  Seq Scan on temp_func_test.functest3
    Output: functest3.a
-(2 rows)
+ Query Identifier: 4255315482610697537
+(3 rows)


ISTM there's probably a good case for suppressing the "Query Identifier"
lines if costs are off. The main reason for saying "costs off" is to
have predictable results, AFAICT, and clearly the query identifier is
not predictable. It would be a trivial change in explain.c. Another
possibility would be to add another option to supporess the query
identifier separately, but that seems like overkill.

Thoughts?


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: [PATCH] support tab-completion for single quote input with equal sign
Next
From: Ranier Vilela
Date:
Subject: Possible fault with resolve column name (plpgsql)