Re: [FEATURE PATCH] pg_stat_statements with plans (v02) - Mailing list pgsql-hackers

From legrand legrand
Subject Re: [FEATURE PATCH] pg_stat_statements with plans (v02)
Date
Msg-id 1521742590947-0.post@n3.nabble.com
Whole thread Raw
In response to Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)  (Julian Markwort <julian.markwort@uni-muenster.de>)
Responses Re: [FEATURE PATCH] pg_stat_statements with plans (v02)  (Arthur Zakirov <a.zakirov@postgrespro.ru>)
List 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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: TOAST table created for partitioned tables
Next
From: Pavel Stehule
Date:
Subject: Re: Re: csv format for psql