Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XMEGK-0001Lu-K9 for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Aug 2014 10:46:04 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XMEGK-00012Y-3f for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Aug 2014 10:46:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XMEGI-00010D-Dy for pgsql-hackers@postgresql.org; Tue, 26 Aug 2014 10:46:02 +0000 Received: from smtp-outbound-1.vmware.com ([208.91.2.12]) by magus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XMEGA-0004DE-Jb for pgsql-hackers@postgresql.org; Tue, 26 Aug 2014 10:45:58 +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 9557729981; Tue, 26 Aug 2014 03:45:49 -0700 (PDT) Received: from EX13-CAS-011.vmware.com (EX13-CAS-011.vmware.com [10.113.191.63]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 8EDC9411FC; Tue, 26 Aug 2014 03:45:49 -0700 (PDT) Received: from EX13-MBX-024.vmware.com (10.113.191.44) by EX13-MBX-003.vmware.com (10.113.191.23) with Microsoft SMTP Server (TLS) id 15.0.775.38; Tue, 26 Aug 2014 03:45:43 -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 03:45:30 -0700 Message-ID: <53FC6545.7000501@vmware.com> Date: Tue, 26 Aug 2014 13:45:25 +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> In-Reply-To: <1409043789.2335.330.camel@jeff-desktop> Content-Type: text/plain; charset="UTF-8"; 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/26/2014 12:03 PM, Jeff Davis wrote: > On Fri, 2014-06-13 at 13:24 +0300, Heikki Linnakangas wrote: >> Attached is a new patch. It now keeps the current pg_clog unchanged, but >> adds a new pg_csnlog besides it. pg_csnlog is more similar to >> pg_subtrans than pg_clog: it's not WAL-logged, is reset at startup, and >> segments older than GlobalXmin can be truncated. > > It appears that this patch weakens the idea of hint bits. Even if > HEAP_XMIN_COMMITTED is set, it still needs to find out if it's in the > snapshot. > > That's fast if the xid is less than snap->xmin, but otherwise it needs > to do a fetch from the csnlog, which is exactly what the hint bits are > designed to avoid. And we can't get around this, because the whole point > of this patch is to remove the xip array from the snapshot. 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. My current thinking is that access to the csnlog will need to be made faster. Currently, it's just another SLRU, but I'm sure we can do better than that. Or add a backend-private cache on top of it; that might already alleviate it enough.. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers