On 12/27/16 11:17 AM, Greg Stark wrote:
On Dec 24, 2016 5:44 PM, "Tom Lane" <t...@sss.pgh.pa.us <mailto:t...@sss.pgh.pa.us>> wrote: I think we'd need at least an order of magnitude cheaper to consider putting timing calls into spinlock or lwlock paths, and that's just not available at all, let alone portably. For spinlocks we could conceivably just bite the bullet and use a raw rdtsc or the equivalent for other platforms. It might be pretty easy to distinguish sane numbers from numbers that result after a process reschedule and we could just discard data when that happens (or count occurrences). That may possibly work for spinlocks but it won't work for anything heavier where process reschedules are routine.
Anything heavier and a ~50ns gettimeofday() call is probably not that bad anymore...
I also wonder if setting an alarm is cheap enough to happen during a spinlock? Set a fairly short alarm on entry, clear it on exit. If the alarm fires, do the gettimeofday(). Add the alarm time back in and you're going to be close enough to when the wait started for any practical use of pg_stat_activity (perhaps this is what Stephen is suggesting about deadlock timeout...)
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
