Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aJlN3-00070S-Bb for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Jan 2016 17:07:37 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aJlN2-0004e0-Uj for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Jan 2016 17:07:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aJlLj-00032e-VQ for pgsql-hackers@postgresql.org; Thu, 14 Jan 2016 17:06:16 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1aJlLc-0001UF-Ab for pgsql-hackers@postgresql.org; Thu, 14 Jan 2016 17:06:15 +0000 Received: by mail.anarazel.de (Postfix, from userid 108) id B3C68860003; Thu, 14 Jan 2016 18:06:07 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail X-Spam-Level: X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from anarazel.de (p54BEB543.dip0.t-ipconnect.de [84.190.181.67]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id C74B1860002; Thu, 14 Jan 2016 18:06:04 +0100 (CET) Received: by anarazel.de (Postfix, from userid 1000) id 4C172102B26; Thu, 14 Jan 2016 18:06:04 +0100 (CET) Date: Thu, 14 Jan 2016 18:06:04 +0100 From: Andres Freund To: Robert Haas Cc: Tom Lane , =?utf-8?B?0JLQsNGB0LjQu9GM0LXQsiDQlNC80LjRgtGA0LjQuQ==?= , "pgsql-hackers@postgresql.org" Subject: Re: Performance degradation in commit ac1d794 Message-ID: <20160114170604.GJ10941@awork2.anarazel.de> References: <19322.1451067023@sss.pgh.pa.us> <19834.1451068135@sss.pgh.pa.us> <20151225211326.z4umuafvv27nczya@alap3.anarazel.de> <24833.1451078993@sss.pgh.pa.us> <20151226112248.uv3qxmroe4va7wke@alap3.anarazel.de> <20160114143931.GG10941@awork2.anarazel.de> <20160114155617.GI10941@awork2.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Pg-Spam-Score: -4.2 (----) 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 On 2016-01-14 11:31:03 -0500, Robert Haas wrote: > On Thu, Jan 14, 2016 at 10:56 AM, Andres Freund wrote: > I think your idea of a data structure the encapsulates a set of events > for which to wait is probably a good one. WaitLatch doesn't seem like > a great name. Maybe WaitEventSet, and then we can have > WaitLatch(&latch) and WaitEvents(&eventset). Hm, I'd like to have latch in the name. It seems far from improbably to have another wait data structure. LatchEventSet maybe? The wait would be implied by WaitLatch. So effectively we'd create a LatchEventSet feLatchSet; somewhere global (and update it from a backend local to the proc latch in SwitchToSharedLatch/SwitchBackToLocalLatch()). Then change all WaitLatch calls to refer to those. Do we want to provide a backward compatible API for all this? I'm fine either way. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers