Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wk8C8-0001vb-4N for pgsql-hackers@arkaria.postgresql.org; Tue, 13 May 2014 08:36:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wk8C7-0002sr-Jk for pgsql-hackers@arkaria.postgresql.org; Tue, 13 May 2014 08:36:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wk8C6-0002sg-87 for pgsql-hackers@postgresql.org; Tue, 13 May 2014 08:36:14 +0000 Received: from smtp-outbound-2.vmware.com ([208.91.2.13]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wk8C3-0006Zo-F3 for pgsql-hackers@postgresql.org; Tue, 13 May 2014 08:36:13 +0000 Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 6886C2838D; Tue, 13 May 2014 01:36:10 -0700 (PDT) Received: from zcs-prod-ext-mta-1.vmware.com (zcs-prod-ext-mta-1.vmware.com [10.113.62.223]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 5EE7E412F6; Tue, 13 May 2014 01:36:10 -0700 (PDT) Received: from zcs-prod-ext-mta-1.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTP id E860A120032; Tue, 13 May 2014 01:36:15 -0700 (PDT) Received: from [192.168.1.90] (zimbra-prod-ext-proxy-vip.vmware.com [10.113.63.87]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTPSA; Tue, 13 May 2014 01:36:14 -0700 (PDT) Message-ID: <5371D977.7000203@vmware.com> Date: Tue, 13 May 2014 11:36:07 +0300 From: Heikki Linnakangas Organization: VMware User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: Rajeev rastogi , Ants Aasma CC: PostgreSQL-development , Markus Wanner Subject: Re: Proposal for CSN based snapshots References: <51B1CB35.4050406@bluegap.ch> <51B6C97B.1070000@bluegap.ch> <5370D323.1070606@vmware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -7.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 05/13/2014 08:08 AM, Rajeev rastogi wrote: >> >The core of the design is to store the LSN of the commit record in >> >pg_clog. Currently, we only store 2 bits per transaction there, >> >indicating if the transaction committed or not, but the patch will >> >expand it to 64 bits, to store the LSN. To check the visibility of an >> >XID in a snapshot, the XID's commit LSN is looked up in pg_clog, and >> >compared with the snapshot's LSN. > Isn't it will be bit in-efficient to look in to pg_clog to read XID's commit > LSN for every visibility check? Maybe. If no hint bit is set on the tuple, you have to check the clog anyway to determine if the tuple is committed. And if for XIDs older than xmin or newer than xmax, you don't need to check pg_clog. But it's true that for tuples with hint bit set, and xmin < XID < xmax, you have to check the pg_clog in the new system, when currently you only need to do a binary search of the local array in the snapshot. My gut feeling is that it won't be significantly slower in practice. If it becomes a problem, some rearrangement pg_clog code might help, or you could build a cache of XID->CSN mappings that you've alread looked up in SnapshotData. So I don't think that's going to be a show-stopper. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers