Re: POC: Cache data in GetSnapshotData() - Mailing list pgsql-hackers

From Mithun Cy
Subject Re: POC: Cache data in GetSnapshotData()
Date
Msg-id CAD__Ouh6PahJ+q1mzzjDzLo4v9GjyufegtJNAyXc0_Lfh-4coQ@mail.gmail.com
Whole thread Raw
In response to Re: POC: Cache data in GetSnapshotData()  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: POC: Cache data in GetSnapshotData()
List pgsql-hackers

On Thu, Mar 17, 2016 at 9:00 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>If you see, for the Base readings, there is a performance increase up till 64 clients and then there is a fall at 88 clients, which to me >indicates that it hits very high-contention around CLogControlLock at 88 clients which CLog patch is able to control to a great degree (if >required, I think the same can be verified by LWLock stats data).  One reason for hitting contention at 88 clients is that this machine >seems to have 64-cores (it has 8 sockets and 8 Core(s) per socket) as per below information of lscpu command.

I am attaching LWLock stats data for above test setups(unlogged tables).

BASEAt 64 clients Block-time unitAt 88 clients Block-time unit
ProcArrayLock182946117827
ClogControlLock107420 120266
clog patch

ProcArrayLock183663 121215
ClogControlLock7280665220
clog patch + save snapshot

ProcArrayLock12826083356
ClogControlLock7892174011

This is for unlogged lables, I mainly see ProcArrayLock have higher contention at 64 clients and at 88 contention is slightly moved to other entities.

--
Thanks and Regards
Mithun C Y

Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Odd system-column handling in postgres_fdw join pushdown patch
Next
From: Ashutosh Bapat
Date:
Subject: Re: Odd system-column handling in postgres_fdw join pushdown patch