> 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
