Horton

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

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>

View thread
From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Janes <jeff.janes@gmail.com>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2011-07-24T17:53:25Z
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

On 07/24/2011 05:55 PM, Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> interesting - iirc we actually had some reports about current libpq
>> behaviour causing scaling issues on some OSes - see
>> http://archives.postgresql.org/pgsql-hackers/2009-06/msg00748.php and
>> some related threads. Iirc the final patch for that was never applied
>> though and the original author lost interest, I think that I was able to
>> measure some noticable performance gains back in the days but I don't
>> think I still have the numbers somewhere.
> 
> Huh?  That patch did get applied in some form or other -- at least,
> libpq does contain references to both SO_NOSIGPIPE and MSG_NOSIGNAL
> these days.


hmm yeah - your are right, when I looked that up a few hours ago I
failed to find the right commit but it was indeed commited:


http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=cea80e726edd42a39bb0220290738f7825de8e57

I think I mentally mixed that up with "compare word-at-a-time in
bcTruelen" patch that was also discussed for affecting query rates for
trivial queries.
I actually wonder if -HEAD would show that issue even more clearly now
that we have parts of roberts performance work in the tree...


Stefan