From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | legrand legrand <legrand_legrand(at)hotmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_stat_statements HLD for futur developments |
Date: | 2018-03-22 09:32:13 |
Message-ID: | alpine.DEB.2.20.1803221019260.23833@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2018-03-22 09:38:33 | Re: [HACKERS] Secondary index access optimizations |
Previous Message | Amit Langote | 2018-03-22 09:31:59 | Re: ON CONFLICT DO UPDATE for partitioned tables |