Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XML1E-0007L1-7P for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Aug 2014 17:58:56 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XML1D-000285-4u for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Aug 2014 17:58:55 +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 1XML1B-00027w-Qu for pgsql-hackers@postgresql.org; Tue, 26 Aug 2014 17:58:53 +0000 Received: from mail-pd0-f176.google.com ([209.85.192.176]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XML17-0004B7-Oq for pgsql-hackers@postgresql.org; Tue, 26 Aug 2014 17:58:52 +0000 Received: by mail-pd0-f176.google.com with SMTP id y10so22740413pdj.7 for ; Tue, 26 Aug 2014 10:58:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:mime-version:content-transfer-encoding; bh=CMizyTtj9zYBO0JHiP7Qul4MGdP8SOiWMDrvGKZzMng=; b=cJQHfROhpKrOGvk6CH4s9b+gwwaEbl2gXkyJMCrpad7eXPFnGQly5ZlJLLB511A61S eCU6QaGJ5Zx2LaZqkF6TF3yhYAA5gZtf9sr/2UcLiiN0KyoakETw4xjCJVYvWlfvmXZs j4DRafiBDS2FOmc/QkcecONRIJ2S38+JUaRp2eLCXUBVw1teeaJpbTOw9pGoj8uytfyN an6QslMb00HFaFWEuC8NFiQUX7K/n4q1sqNOcVn4yO1xS95LiIrAb20/0vkaMo5sAHop exC4YEKIxcMLvukgytFpXyjsS/HD4W3AVdp8Uhwu0FmyHmzXs5F9dMgd7QBCiAjb1qB3 Tv+A== X-Gm-Message-State: ALoCoQlVD6hvu8dzNalhYmTsUTbM0J3snNwbUPiLhjd62C4cgZptSScEo867Z3l8uFWIMhxqmiAN X-Received: by 10.66.139.36 with SMTP id qv4mr39408449pab.53.1409075926834; Tue, 26 Aug 2014 10:58:46 -0700 (PDT) Received: from [192.168.0.105] (c-69-181-249-16.hsd1.ca.comcast.net. [69.181.249.16]) by mx.google.com with ESMTPSA id zm5sm3840979pbb.76.2014.08.26.10.58.45 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 26 Aug 2014 10:58:46 -0700 (PDT) Message-ID: <1409075935.2335.358.camel@jeff-desktop> Subject: Re: Proposal for CSN based snapshots From: Jeff Davis To: Heikki Linnakangas Cc: Greg Stark , Robert Haas , Andres Freund , Alvaro Herrera , Bruce Momjian , Rajeev rastogi , Ants Aasma , PostgreSQL-development , Markus Wanner Date: Tue, 26 Aug 2014 10:58:55 -0700 In-Reply-To: <53FC6545.7000501@vmware.com> 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) 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 Tue, 2014-08-26 at 13:45 +0300, Heikki Linnakangas wrote: > 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.. Aren't those the same ideas that have been proposed for eliminating hint bits? If this patch makes taking snapshots much faster, then perhaps it's enough incentive to follow through on one of those ideas. I am certainly open to removing hint bits (which was probably clear from earlier discussions) if there are significant wins elsewhere and the penalty is not too great. To continue the discussion on this patch, let's assume that we make TransactionIdGetCommitLSN sufficiently fast. If that's the case, can't we make HeapTupleSatisfiesMVCC look more like: LsnMin = TransactionIdGetCommitLSN(xmin); if (!COMMITLSN_IS_COMMITTED(LsnMin)) LsnMin = BIG_LSN; LsnMin = TransactionIdGetCommitLSN(xmin); if (!COMMITLSN_IS_COMMITTED(LsnMin)) LsnMin = BIG_LSN; return (snapshot->snapshotlsn >= LsnMin && snapshot->snapshotlsn < LsnMax); There would need to be some handling for locked tuples, or tuples related to the current transaction, of course. But I still think it would turn out simpler; perhaps by enough to save a few cycles. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers