Greg Stark <st...@mit.edu> writes:
> 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? 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
