> 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

In Thread:
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
  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
There is a risk of duplicated informations (like execution_time, calls, ...)


Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html

Reply via email to