Re: POC: Cache data in GetSnapshotData()
От | Jim Nasby |
---|---|
Тема | Re: POC: Cache data in GetSnapshotData() |
Дата | |
Msg-id | 56362CCF.9070204@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: POC: Cache data in GetSnapshotData() (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: POC: Cache data in GetSnapshotData()
|
Список | pgsql-hackers |
On 5/25/15 10:04 PM, Amit Kapila wrote: > On Tue, May 26, 2015 at 12:10 AM, Andres Freund <andres@anarazel.de > <mailto:andres@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/E8870A2F6A4B1045B1C292B77EAB207C77069A80@SZXEMA501-MBX.china.huawei.com Anything happen with this? -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: