Re: testing ProcArrayLock patches

Kevin Grittner <kevin.grittner@wicourts.gov>

From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>

To: "Pavan Deolasee" <pavan.deolasee@gmail.com>

Cc: "Robert Haas" <robertmhaas@gmail.com>, <pgsql-hackers@postgresql.org>

Date: 2011-11-21T23:10:35Z

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 →

Don't elide blank lines when accumulating psql command history.
- ff4fd4bf53c5 9.2.0 cited

Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
 
> It will be a great help if you could spare few minutes to also
> test the patch to take out the frequently accessed PGPROC members
> to a different array. We are seeing good improvements on HPUX IA
> platform and the AMD Opteron and it will be interesting to know
> what happens on the Intel platform too.
 
For a read only comparison (which was run using the simple
protocol), using identical settings to the previous master run, but
with the PGPROC split patch:
 
m32 tps = 201738.209348 (including connections establishing)
p32 tps = 201620.966988 (including connections establishing)

m128 tps = 352159.631878 (including connections establishing)
p128 tps = 363998.703900 (including connections establishing)
 
Clearly a win at 128 clients; not at 32.
 
For updates:
 
sm32 tps = 27392.393850 (including connections establishing)
sp32 tps = 27995.784333 (including connections establishing) 
 
sm128 tps = 22261.902571 (including connections establishing)
sp128 tps = 23690.408272 (including connections establishing)
 
pm32 tps = 34983.352396 (including connections establishing)
pp32 tps = 36076.373389 (including connections establishing)
 
pm128 tps = 24164.441954 (including connections establishing)
pp128 tps = 27070.824588 (including connections establishing)
 
That's a pretty decisive win all around.
 
-Kevin