Re: pgbench cpu overhead (was Re: lazy vxid locks, v1) - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject Re: pgbench cpu overhead (was Re: lazy vxid locks, v1)
Date
Msg-id 4E2C5C15.2080705@kaltenbrunner.cc
Whole thread Raw
In response to Re: pgbench cpu overhead (was Re: lazy vxid locks, v1)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: XPATH vs. server_encoding != UTF-8
Next
From: Florian Pflug
Date:
Subject: Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON