pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Rajeev rastogi <rajeev.rastogi@huawei.com>
To: Ants Aasma <ants@cybertec.at>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Markus Wanner <markus@bluegap.ch>
Subject: Re: Proposal for CSN based snapshots
Date: Tue, 13 May 2014 11:36:07 +0300
Message-ID: <5371D977.7000203@vmware.com> (raw)
In-Reply-To: <BF2827DCCE55594C8D7A8F7FFD3AB7713DDE95E7@SZXEML508-MBX.china.huawei.com>
References: <CA+CSw_tEpJ=md1zgxPkjH6CWDnTDft4gBi=+P9SnoC+Wy3pKdA@mail.gmail.com>
	<51B1CB35.4050406@bluegap.ch>
	<CA+CSw_uSzXidemci-nU5fJY-qXD0DE0ZWz-j1ASTT_ffBjXo9Q@mail.gmail.com>
	<51B6C97B.1070000@bluegap.ch>
	<BF2827DCCE55594C8D7A8F7FFD3AB7713DDBC758@SZXEML508-MBX.china.huawei.com>
	<5370D323.1070606@vmware.com>
	<BF2827DCCE55594C8D7A8F7FFD3AB7713DDE95E7@SZXEML508-MBX.china.huawei.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

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



view thread (113+ messages)  latest in thread

Message-ID: <5371D977.7000203@vmware.com>
Permalink:  ../5371D977.7000203@vmware.com/
Also on:    postgresql.org/message-id/5371D977.7000203@vmware.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: hlinnakangas@vmware.com, rajeev.rastogi@huawei.com, ants@cybertec.at, markus@bluegap.ch
  Subject: Re: Proposal for CSN based snapshots
  In-Reply-To: <5371D977.7000203@vmware.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox