Hello,
> 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 ?
None? As for any feature, some people may have some plans, that they may
end up developing or not. If developed, it may end up committed or not.
Kind of a Darwinian process which involves a degree of randomness.
> Could a PLANID column be added to help new developments working on plans and parameters ?
Dunno. I understand that the underlying suggestion is that selected plans
may be kept as queries are kept, and that you are refering to
"https://commitfest.postgresql.org/17/1470/".
Maybe ask your question on the corresponding thread, and contribute to
reviewing the patch?
As the same plan may be used for two distinct queries and one query may
yield distinct plans, I'd guess that there is a potential n-n
relationship, but maybe it is simpler to keep a list of plans attached to
their queries somehow.
> 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) ?
Out of the box I'd be fine with a pg_stat_plans, and some mapping between
plans and statements.
--
Fabien.
