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

Reply via email to