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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to