Skip site navigation (1) Skip section navigation (2)

Re: tracking context switches with perf record

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: tracking context switches with perf record
Date: 2012-03-30 17:51:41
Message-ID: 25230.1333129901@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark <stark(at)mit(dot)edu> writes:
> On Fri, Mar 30, 2012 at 5:27 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-03-30 17:55:52
Subject: Re: tracking context switches with perf record
Previous:From: Tom LaneDate: 2012-03-30 17:49:24
Subject: Re: pg_dump incredibly slow dumping a single schema from a large db

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group