On Thu, Nov 7, 2013 at 8:21 PM, Greg Stark <st...@mit.edu> wrote: > > > The most interesting thing that I could see calculating from these stats > would require also knowing how much time was spent waiting on writes and > reads on the network. With the cumulative time spent as well as the count of > syscalls you can calculate the average latency over any time period between > two snapshots. However that would involve adding two gettimeofday calls > which would be quite likely to cause a noticeable impact on some > architectures. Unless there's already a pair of gettimeofday calls you can > piggy back onto? > >
Adding timing instrumentation to each send() and recv() would require over 50 calls to gettimeofday for a simple psql -c "SELECT 1", while the client was waiting. That would add ~40usec extra time (estimated using pg_test_timing on my laptop without TSC). It might be more overhead than it's worth. -nigel. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers