From: | Daniel Wood <hexexpert(at)comcast(dot)net> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Wait profiling |
Date: | 2020-07-10 20:23:40 |
Message-ID: | 1498979608.43952.1594412620837@connect.xfinity.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
After nearly 5 years does something like the following yet exist?
https://www.postgresql.org/message-id/559D4729.9080704@postgrespro.ru
I feel that it would be useful to have the following two things. One PG enhancement and one standard extension.
1) An option to "explain" to produce a wait events profile.
postgres=# explain (analyze, waitprofile) update pgbench_accounts set bid=bid+1 where aid < 2000000;
...
Execution time: 23111.231 ms
62.6% BufFileRead
50.0% CPU
9.3% LWLock
It uses a PG timer to do this.
2) An extension based function like: select pg_wait_profile(pid, nSeconds, timerFrequency) to return the same thing for an already running query. Useful if you want examine some already long running query that is taking too long.
Neither of these would be doing the heavy weight pg_stat_activity but directly poll the wait event in PROC. I've already coded the EXPLAIN option.
Furthermore, can't we just remove the following "IF" test from pgstat_report_wait_{start,end}?
if (!pgstat_track_activities || !proc)
return;
Just do the assignment of wait_event_info always. We should use a dummy PGPROC assigned to MyProc until we assign the one in the procarray in shared memory. That way we don't need the "!proc" test.
About the only thing I'd want to verify is whether wait_event_info is on the same cache lines as anything else having to do with snapshots.
If I recall correctly the blanks lines above I've used to make this more readable will disappear. :-(
- Dan Wood
From | Date | Subject | |
---|---|---|---|
Next Message | Michail Nikolaev | 2020-07-10 20:25:15 | Re: [PATCH] Btree BackwardScan race condition on Standby during VACUUM |
Previous Message | Tom Lane | 2020-07-10 20:10:46 | Re: Created feature for to_date() conversion using patterns 'YYYY-WW', 'YYYY-WW-D', 'YYYY-MM-W' and 'YYYY-MM-W-D' |