Re: Proposal for CSN based snapshots

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Ants Aasma <ants(at)cybertec(dot)at>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Markus Wanner <markus(at)bluegap(dot)ch>
Subject: Re: Proposal for CSN based snapshots
Date: 2014-05-14 04:16:11
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB7713DDE9AB2@SZXEML508-MBX.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 13 May 2014 14:06, Heikki Linnakangas

> >> >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.

Yes definitely it should not be not show-stopper. This can be optimized later by method
as you mentioned and also by some cut-off technique based on which we can
decide that a XID beyond a certain range will be always visible, and thereby
avoiding look-up in pg_clog.

Thanks and Regards,
Kumar Rajeev Rastogi

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Muraviov 2014-05-14 04:33:01 Re: sepgsql: label regression test failed
Previous Message Tom Lane 2014-05-14 03:42:51 Re: gettimeofday is at the end of its usefulness?