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

Reply via email to