On Sun, Nov 1, 2015 at 8:46 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
> On 5/25/15 10:04 PM, Amit Kapila wrote: > >> On Tue, May 26, 2015 at 12:10 AM, Andres Freund <and...@anarazel.de >> <mailto:and...@anarazel.de>> wrote: >> > >> > On 2015-05-20 19:56:39 +0530, Amit Kapila wrote: >> > > I have done some tests with this patch to see the benefit with >> > > and it seems to me this patch helps in reducing the contention >> > > around ProcArrayLock, though the increase in TPS (in tpc-b tests >> > > is around 2~4%) is not very high. >> > > >> > > pgbench (TPC-B test) >> > > ./pgbench -c 64 -j 64 -T 1200 -M prepared postgres >> > >> > Hm, so it's a read mostly test. >> >> Write not *Read* mostly. >> >> > I probably not that badly contended on >> > the snapshot acquisition itself. I'd guess a 80/20 read/write mix or so >> > would be more interesting for the cases where we hit this really bad. >> > >> >> Yes 80/20 read/write mix will be good test to test this patch and I think >> such a load is used by many applications (Such a load is quite common >> in telecom especially their billing related applications) and currently >> we don't >> have such a test handy to measure performance. >> >> On a side note, I think it would be good if we can add such a test to >> pgbench or may be use some test which adheres to TPC-C specification. >> Infact, I remember [1] people posting test results with such a workload >> showing ProcArrayLock as contention. >> >> >> [1] - >> >> http://www.postgresql.org/message-id/e8870a2f6a4b1045b1c292b77eab207c77069...@szxema501-mbx.china.huawei.com >> > > Anything happen with this? > No. I think one has to study the impact of this patch on latest code especially after commit-0e141c0f. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
