Re: tracking context switches with perf record

From: Greg Stark <stark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: tracking context switches with perf record
Date: 2012-03-30 17:30:05
Message-ID: CAM-w4HM4kd0TWkW3XayBiPEb0jSbUfugY24qPV_S35dZ=N8wrQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-03-30 17:30:26 Re: pg_dump incredibly slow dumping a single schema from a large db
Previous Message Daniel Farina 2012-03-30 17:21:11 Re: HTTP Frontend? (and a brief thought on materialized views)