Greg Stark <stark@mit.edu> writes:
> 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? 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, that would be on libpq's head if it were true, but I believe we're
fairly careful to not flush the output buffer until we're sending a
complete message.
regards, tom lane