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 <coe...@cri.ensmp.fr> Envoyé : jeudi 22 mars 2018 09:32:13 À : legrand legrand Cc : pgsql-hack...@postgresql.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.
