On Fri, Mar 30, 2012 at 1:30 PM, Greg Stark <stark@mit.edu> wrote:
> On Fri, Mar 30, 2012 at 5:27 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> If you expand that branch of the call tree, you find that all of them
>> are coming eventually from secure_read; the server is waiting for a
>> new query from the client. This is, obviously, overhead we can't
>> eliminate from this test; waiting for the client is part of the job.
>
> Fwiw this isn't necessarily true. How does the absolute number of
> these events compare with the number of pg_bench operations done?
Since perf is a stochastic profiler, I don't think there's any way to
measure that using this tool.
> If
> it's significantly more the server could be reading on sockets while
> there are partial commands there and it might be more efficient to
> wait until the whole command is ready before reading. It may be that
> this indicates that pg_bench is written in an inefficient way and it
> should pipeline more commands but of course optimizing pg_bench is
> kind of missing the point.
Well, to some degree. I think most clients are going to send commands
one at a time and wait for the responses. OTOH, if for example libpq
is sending the data inefficiently in some way that wouldbe worth
fixing; lots of people use libpq.
> Also incidentally context switches is one of the things getrusage
> shows so I'm still hoping to have that per-plan-node though that's
> orthogonal to what this tool gives you with the call graph.
Yeah.
Actually, what is really bugging me is that I cannot find any way of
getting a profile that reflects the *time* spent waiting rather than
merely the *number* of waits. That seems like an obvious thing to
want, and I cannot find a way to get it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
