Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XMWus-0002hn-Ff for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Aug 2014 06:41:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XMWur-0005P8-Cb for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Aug 2014 06:41:09 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XMWup-0005OM-Vr for pgsql-hackers@postgresql.org; Wed, 27 Aug 2014 06:41:08 +0000 Received: from smtp-outbound-1.vmware.com ([208.91.2.12]) by makus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XMWum-0001GR-QE for pgsql-hackers@postgresql.org; Wed, 27 Aug 2014 06:41:06 +0000 Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 6C8982AE4A; Tue, 26 Aug 2014 23:41:02 -0700 (PDT) Received: from EX13-CAS-004.vmware.com (EX13-CAS-004.vmware.com [10.113.191.54]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 61AF341422; Tue, 26 Aug 2014 23:41:02 -0700 (PDT) Received: from EX13-MBX-024.vmware.com (10.113.191.44) by EX13-MBX-004.vmware.com (10.113.191.24) with Microsoft SMTP Server (TLS) id 15.0.775.38; Tue, 26 Aug 2014 23:41:02 -0700 Received: from [192.168.1.90] (10.113.160.246) by EX13-MBX-024.vmware.com (10.113.191.44) with Microsoft SMTP Server (TLS) id 15.0.775.38; Tue, 26 Aug 2014 23:41:01 -0700 Message-ID: <53FD7D65.9040602@vmware.com> Date: Wed, 27 Aug 2014 09:40:37 +0300 From: Heikki Linnakangas Organization: VMware User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Jeff Davis CC: Greg Stark , Robert Haas , "Andres Freund" , Alvaro Herrera , Bruce Momjian , Rajeev rastogi , Ants Aasma , PostgreSQL-development , Markus Wanner Subject: Re: Proposal for CSN based snapshots References: <51B6C97B.1070000@bluegap.ch> <5370D323.1070606@vmware.com> <20140512144112.GB9619@awork2.anarazel.de> <5370E267.2020904@vmware.com> <20140515183436.GD25053@momjian.us> <20140515200632.GB16014@awork2.anarazel.de> <20140515213714.GB7857@eldon.alvh.no-ip.org> <53889CCB.7030005@vmware.com> <20140530152721.GC30516@awork2.anarazel.de> <5388D02D.6040305@vmware.com> <539AD153.9000004@vmware.com> <1409043789.2335.330.camel@jeff-desktop> <53FC6545.7000501@vmware.com> <1409116988.2335.463.camel@jeff-desktop> In-Reply-To: <1409116988.2335.463.camel@jeff-desktop> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.160.246] X-ClientProxiedBy: EX13-CAS-013.vmware.com (10.113.191.65) To EX13-MBX-024.vmware.com (10.113.191.44) X-Pg-Spam-Score: -6.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 On 08/27/2014 08:23 AM, Jeff Davis wrote: > On Tue, 2014-08-26 at 13:45 +0300, Heikki Linnakangas wrote: >> Yeah. This patch in the current state is likely much much slower than >> unpatched master, except in extreme cases where you have thousands of >> connections and short transactions so that without the patch, you spend >> most of the time acquiring snapshots. > > What else are you looking to accomplish with this patch during this > 'fest? Bug finding? Design review? Performance testing? Design review, mostly. I know the performance still sucks. Although if you can foresee some performance problems, aside from the extra CSNLOG lookups, it would be good to know. > I think there's already at least one design issue to consider, which is > whether we care about CLOG/CSNLOG access for hinted records where the > xid > snapshot->xmin (that is, accesses that previously would have > looked at xip). Would more discussion help here or do we need to wait > for performance numbers? I think my current plan is to try to make that CSNLOG lookup fast. In essence, rewrite SLRUs to be more performant. That would help with the current clog, too, which would make it more feasible to set hint bits less often. In particular, avoid dirtying pages just to set hint bits. I'm not sure if that's enough - you can't beat checking a single hint bit in the same cache line as the XID - but I think it's worth a try. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers