From: | Nigel Heron <nheron(at)querymetrics(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com> |
Subject: | Re: stats for network traffic WIP |
Date: | 2013-11-11 22:14:24 |
Message-ID: | CAHhq2w+k3T3kCikgdeTY3fp0dpWBBNbqRU0KqxHSCwYy+ACZ2A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 7, 2013 at 8:21 PM, Greg Stark <stark(at)mit(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-11-11 22:18:18 | Re: Clang 3.3 Analyzer Results |
Previous Message | Robert Haas | 2013-11-11 21:40:49 | Re: [v9.4] row level security |