Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1a7Rl0-0006RR-GR for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Dec 2015 17:45:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1a7Rkz-0004Cq-W1 for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Dec 2015 17:45:26 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1a7Rjf-0002g9-UY for pgsql-hackers@postgresql.org; Fri, 11 Dec 2015 17:44:04 +0000 Received: from newmail.postgrespro.ru ([93.174.131.138] helo=mail.postgrespro.ru) by makus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1a7Rjc-0002Rp-DX for pgsql-hackers@postgresql.org; Fri, 11 Dec 2015 17:44:02 +0000 Received: from fujitsu (unknown [188.123.231.37]) by mail.postgrespro.ru (Postfix) with ESMTPSA id 19BD121C4C91; Fri, 11 Dec 2015 20:43:58 +0300 (MSK) Date: Fri, 11 Dec 2015 20:42:19 +0300 From: Aleksander Alekseev To: Tom Lane Cc: pgsql-hackers@postgresql.org Subject: Re: Patch: fix lock contention for HASHHDR.mutex Message-ID: <20151211204219.273b3acb@fujitsu> In-Reply-To: <20151211191441.3cc507b5@fujitsu> References: <20151211170001.78ded9d7@fujitsu> <772.1449847830@sss.pgh.pa.us> <20151211191441.3cc507b5@fujitsu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Oops. s/approve or disapprove/confirm or deny/ On Fri, 11 Dec 2015 19:14:41 +0300 Aleksander Alekseev wrote: > Hello, Tom > > I see your point, but I would like to clarify a few things. > > 1. Do we consider described measurement method good enough to conclude > that sometimes PostgreSQL really spends 3 ms in a spinlock (like a RTT > between two Internet hosts in the same city)? If not, what method > should be used to approve or disapprove this? > > 2. If we agree that PostgreSQL does sometimes spend 3 ms in a spinlock > do we consider this a problem? > > 3. If we consider this a problem, what method is considered > appropriate to find a real reason of such behaviour so we could fix > it? > > Best regards, > Aleksander > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers