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
