Horton

Re: pgbench cpu overhead (was Re: lazy vxid locks, v1)

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2011-07-24T15:46:49Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid extra system calls to block SIGPIPE if the platform provides either

Jeff Janes <jeff.janes@gmail.com> writes:
> How was this profile generated?  I get a similar profile using
> --enable-profiling and gprof, but I find it not believable.  The
> complete absence of any calls to libpq is not credible.  I don't know
> about your profiler, but with gprof they should be listed in the call
> graph even if they take a negligible amount of time.  So I think
> pgbench is linking to libpq libraries that do not themselves support
> profiling (I have no idea how that could happen though).  If the calls
> graphs are not getting recorded correctly, surely the timing can't be
> reliable either.

Last I checked, gprof simply does not work for shared libraries on
Linux --- is that what you're testing on?  If so, try oprofile or
some other Linux-specific solution.

			regards, tom lane