On Fri, Mar 30, 2012 at 1:30 PM, Greg Stark <st...@mit.edu> wrote: > On Fri, Mar 30, 2012 at 5:27 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
