Skip site navigation (1) Skip section navigation (2)

Re: testing ProcArrayLock patches

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: testing ProcArrayLock patches
Date: 2011-11-22 18:04:48
Message-ID: CABOikdOOLPLB_pa3YSVrJdqZJWT9BRCSzxeM32zDdTU9ss3JOg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Nov 22, 2011 at 4:40 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)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.
>

Thanks for running those tests. The numbers are not that bad, but
definitely not as good as we saw on some other platforms. But its
possible that they may improve in percentage terms with even more
number of clients on this box. And given that we are seeing big gains
on other platforms, hopefully it will give us confident to proceed
with the patch.

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-11-22 19:04:01
Subject: Re: testing ProcArrayLock patches
Previous:From: Tom LaneDate: 2011-11-22 18:01:23
Subject: Re: Singleton range constructors versus functional coercion notation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group