From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: POC: Cache data in GetSnapshotData() |
Date: | 2015-05-26 03:04:31 |
Message-ID: | CAA4eK1++jcA90FFjMAmiUcLLPB8vtbZ5BA=gOWCdCQEBnArgJg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 26, 2015 at 12:10 AM, Andres Freund <andres(at)anarazel(dot)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.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-05-26 03:05:51 | Re: anole: assorted stability problems |
Previous Message | Tom Lane | 2015-05-26 02:45:50 | Re: brin regression test intermittent failures |