Date: Thu, 5 Dec 2013 10:18:41 +0100
From: Andres Freund <andres@2ndquadrant.com>
To: Metin Doslu <metin@citusdata.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 Amit Kapila <amit.kapila16@gmail.com>,
 Claudio Freire <klaussfreire@gmail.com>
Subject: Re: Parallel Select query performance and shared buffers
Message-ID: <20131205091841.GE28793@alap2.anarazel.de>
References: 
 <CAL1dPcfZJFO2gr+53mU14VrrHxT-Bs6QOYgzQNV_VgxnkKUaZA@mail.gmail.com>
 <CAL1dPcdm1q0q0VtOpe2gfOyCwS7FkzURw=ZQ1RsLgfKgz5=gMg@mail.gmail.com>
 <CAL1dPccxwZkh8Vih4X0kKSCtGA-S7HasmRZe49TK3bqqy2rSBg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAL1dPccxwZkh8Vih4X0kKSCtGA-S7HasmRZe49TK3bqqy2rSBg@mail.gmail.com>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 2013-12-05 11:15:20 +0200, Metin Doslu wrote:
> > - When we increased NUM_BUFFER_PARTITIONS to 1024, this problem is
> > disappeared for 8 core machines and come back with 16 core machines on
> > Amazon EC2. Would it be related with PostgreSQL locking mechanism?
> 
> If we build with -DLWLOCK_STATS to print locking stats from PostgreSQL, we
> see tons of contention with default value of NUM_BUFFER_PARTITIONS which is
> 16:

Is your workload bigger than RAM? I think a good bit of the contention
you're seeing in that listing is populating shared_buffers - and might
actually vanish once you're halfway cached.