Planning counters in pg_stat_statements (using pgss_store)

From: legrand legrand <legrand_legrand(at)hotmail(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Planning counters in pg_stat_statements (using pgss_store)
Date: 2018-12-29 23:27:18
Message-ID: DB6PR0301MB21352F6210E3B11934B0DCC790B00@DB6PR0301MB2135.eurprd03.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Starting from
https://www.postgresql.org/message-id/CAEepm%3D2vORBhWQZ1DJmKXmCVi%2B15Tgrv%2B9brHLanWU7XE_FWxQ%40mail.gmail.com

Here is a patch trying to implement what was proposed by Tom Lane:

"What we could/should do instead, I think, is have pgss_planner_hook
make its own pgss_store() call to log the planning time results
(which would mean we don't need the added PlannedStmt field at all).
That would increase the overhead of this feature, which might mean
that it'd be worth having a pg_stat_statements GUC to enable it.
But it'd be a whole lot cleaner."

Now:
pgss_post_parse_analyze, initialize pgss entry with sql text,
pgss_planner_hook, adds planning_time and counts,
pgss_ExecutorEnd, works unchanged.

but doesn't include any pg_stat_statements GUC to enable it yet.

note: I didn't catch the sentence "which would mean we don't need the added PlannedStmt field at all".

Regarding initial remark from Thomas Munro:

"I agree with the sentiment on the old thread that
{total,min,max,mean,stddev}_time now seem badly named, but adding
execution makes them so long... Thoughts?"

What would you think about:
- userid
- dbid
- queryid
- query
- plans
- plan_time
- {min,max,mean,stddev}_plan_time
- calls
- exec_time
- {min,max,mean,stddev}_exec_time
- total_time (being the sum of plan_time and exec_time)
- rows
- ...

Regards
PAscal

Attachment Content-Type Size
pgss_add_planning_counters.diff application/octet-stream 18.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-12-29 23:36:38 Re: Optimize constant MinMax expressions
Previous Message Tom Lane 2018-12-29 23:14:58 Re: Mutability of domain CHECK constraints