Wait profiling - Mailing list pgsql-hackers

From Daniel Wood
Subject Wait profiling
Date
Msg-id 1498979608.43952.1594412620837@connect.xfinity.com
Whole thread Raw
In response to Re: Corruption during WAL replay  (Teja Mupparti <tejeswarm@hotmail.com>)
Responses Re: Wait profiling  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
After nearly 5 years does something like the following yet exist?

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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Created feature for to_date() conversion using patterns 'YYYY-WW', 'YYYY-WW-D', 'YYYY-MM-W' and 'YYYY-MM-W-D'
Next
From: Michail Nikolaev
Date:
Subject: Re: [PATCH] Btree BackwardScan race condition on Standby during VACUUM