On Wed, Dec 28, 2016 at 1:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jim Nasby <jim.na...@bluetreble.com> writes: >> On 12/28/16 11:25 AM, Tom Lane wrote: >>> The idea of just capturing the wait start for heavyweight locks, and >>> not other lock types, still seems superior to any of the alternatives >>> that have been suggested ... > >> Is some kind of alarm a viable option for the others? If setting the >> alarm is cheap, > > Setting an alarm is certain to require a gettimeofday and/or a kernel > call. It is far from cheap.
If one were OK with a really-really-rough value for when the wait started, you could have a slot for a timestamp in PGPROC that is cleared by pgstat_report_wait_end() but not set by pgstat_report_wait_start(). Then you could have a background process that goes through and sets it for all processes advertising a wait event every second, or every 10 seconds, or every half second, or whatever you want. Of course this doesn't eliminate the overhead but it pushes it into the background which, if there are idle CPUs, is almost as good. I previously proposed something similar to this as a way of profiling waits and I believe you weren't very supportive of it, but I still think these kinds of ideas have some legs. We can neither take the approach that timestamp overhead is irrelevant nor the position that timestamps are expensive so let's not have any. Some third way has to be found. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
