Re: testing with pg_stat_statements - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: testing with pg_stat_statements
Date
Msg-id CAOBaU_YSV4QpmmeZuZ7RxsKBZv_Q3N6AnhvxOB3_WtEEhkqi=Q@mail.gmail.com
Whole thread Raw
In response to testing with pg_stat_statements  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Fri, Sep 17, 2021 at 3:08 AM Andrew Dunstan <andrew@dunslane.net> wrote:
>
> 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.

That's something I also regularly do when working on patches, so I
confirm that there's no problem with pg_stat_statements, at least to
my knowledge.

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

Yes that's something that I also find annoying.  I'm not sure if
removing the queryid when costs is disabled is the best way forward,
but I have no strong objection.

Note that we do have a test in explain.sql to make sure that a queryid
is computed and outputed in explain plans, but it doesn't rely on
costs being disabled so that wouldn't be a problem.



pgsql-hackers by date:

Previous
From: Sehrope Sarkuni
Date:
Subject: Re: Add jsonlog log_destination for JSON server logs
Next
From: Michael Paquier
Date:
Subject: Re: Add jsonlog log_destination for JSON server logs