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