RE: pg_stat_statements HLD for futur developments
От | Fabien COELHO |
---|---|
Тема | RE: pg_stat_statements HLD for futur developments |
Дата | |
Msg-id | alpine.DEB.2.20.1803221340180.23833@lancre обсуждение исходный текст |
Ответ на | RE: pg_stat_statements HLD for futur developments (legrand legrand <legrand_legrand@hotmail.com>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: