> I've created a draft patch that provides access to plans in a view
> called pg_stat_statements_plans.
++ I like it !
> There is no column that indicates whether the plan is "good" or "bad",
> because that is evident from the execution time of both plans and because
> that would require some kind of plan_type for all plans that might
> be stored in future versions.
At startup time there are 2 identical plans found in the view
I thought it should have be only one: the "initial" one
(as long as there is no "good" or "bad" one).
maybe 3 "plan_types" like "init", "good" and "bad" should help.
Will a new line be created for good or bad plan if the plan is the same ?
shouldn't we capture "constants" and "parameters" inspite ?
Is query text needed in plan?
it can be huge and is already available (in normalized format)
in pg_stat_statements. If realy needed in raw format
(with constants) we could force pgss to store it (in replacement of
normalize one)
using a guc pg_stat_statements.normalized = false (I have a patch to do
that).
In Thread:
http://www.postgresql-archive.org/Poc-pg-stat-statements-with-planid-td6014027.html
pg_stat_statements view has a new key with dbid,userid,queryid + planid
and 2 columns added: "created" and "last_updated".
May be your view pg_stat_statements_plans could be transformed :
same key as pgss: dbid,userid,queryid,planid
and THE plan column to store explain result (no more need for plan_time nor
tz that
are already available in modified pgss).
Thoses changes to pgss are far from being accepted by community:
- planid calculation has to be discussed (I reused the one from
pg_stat_plans,
but I would have prefered explain command to provide it ...),
- "created" and "last_updated" columns also,
- ...
So maybe your stategy to keep pgss unchanged, and add extensions view is
better.
There is a risk of duplicated informations (like execution_time, calls, ...)
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html