Re: [FEATURE PATCH] pg_stat_statements with plans (v02)

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

In response to

Responses

Browse pgsql-hackers by date

  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