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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers