RE: pg_stat_statements HLD for futur developments

Thank you Fabien.

My question is more as there are so many developments arround pg_stat_statements (see the list at the end of the initial post):

What is the roadmap for its design ?

Could a PLANID column be added to help new developments working on plans and parameters ?

Could all the new columns be added to the actual view, or should they be added to others

like pg_stat_statements_plans or pg_stat_statements_parameters reusing pgss's pk (userid, dbid, queryid, planid) ?

Regards

PAscal

________________________________
De : Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Envoyé : jeudi 22 mars 2018 09:32:13
À : legrand legrand
Cc : pgsql-hackers(at)postgresql(dot)org
Objet : Re: pg_stat_statements HLD for futur developments

Hello,

> As a new user of PostgreSQL, I have started using pg_stat_statements, and
> was pleased but a little surprised:
>
> First of all, the normalized form of the query string makes it impossible to
> be used in EXPLAIN commands.

Yes, because of the normalization.

> Second, normalized constants and parameters values where missing to be able
> to test optimizations results manually with EXPLAIN.

The normalization is entirely voluntary. Otherwise, probably every query
would generate a distinct entry, which for a high load system would be a
very bad idea, and there would be no point to the extension.

Note that with recent pg you can reuse the query with with a PREPARE, and
then EXPLAIN on the EXECUTE.

PREPARE foo(INT) AS <the-query-with-its-dollar-vars>;
EXPLAIN EXECUTE foo(5432);
EXPLAIN EXECUTE foo(2345);
DEALLOCATE foo;

> Third, execution plan was not available (making usage of AUTO_EXPLAIN

Yep, but ISTM that the plan might differ depending on the actual values,
so it would not make much sense to keep it anyway.

--
Fabien.