From: | legrand legrand <legrand_legrand(at)hotmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [FEATURE PATCH] pg_stat_statements with plans (v02) |
Date: | 2018-03-22 18:16:30 |
Message-ID: | 1521742590947-0.post@n3.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
I'm very interested in pg_stat_statements usage, and I'm very happy to see
you adding plans to it.
Reading other pg_stat_statements threads on this forum, there are also activ
developments to add:
- planing duration,
- first date,
- last_update date,
- parameters for normalized queries,
- ...
as described in
http://www.postgresql-archive.org/pg-stat-statements-HLD-for-futur-developments-td6012381.html
I was wondering about how would your dev behave with all those new features.
It seems to me that bad and good plans will not have any of thoses
informations.
What would you think about displaying good, current, bad plans results in 3
lines inspite of only one line ?
queryid, plantype, query, ...
aaa good ...
aaa current ...
aaa bad ...
This would permit to get planing duration, first capture time, last capture,
executions, query parameters for all plans (good or bad inclusive).
Last question, didn't you think about a model to store all the different
plans using a planid like
queryid, planid, query, ...
aaa plan1 ...
aaa plan2 ...
aaa plan3 ...
...
I can not imagine that there would be so many of them ;o)
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-03-22 18:28:14 | Re: Re: csv format for psql |
Previous Message | Robert Haas | 2018-03-22 17:51:26 | Re: TOAST table created for partitioned tables |