On Fri, Oct 20, 2017 at 5:47 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > I think what we need here is a way to register satisfies function > (SnapshotSatisfiesFunc) in SnapshotData for different storage engines.
I don't see how that helps very much. SnapshotSatisfiesFunc takes a HeapTuple as an argument, and it cares in detail about that tuple's xmin, xmax, and infomask, and it sets hint bits. All of that is bad, because an alternative storage engine is likely to use a different format than HeapTuple and to not have hint bits (or at least not in the same form we have them now). Also, it doesn't necessarily have a Boolean answer to the question "can this snapshot see this tuple?". It may be more like "given this TID, what tuple if any can I see there?" or "given this tuple, what version of it would I see with this snapshot?". Another thing to consider is that, if we could replace satisfiesfunc, it would probably break some existing code. There are multiple places in the code that compare snapshot->satisfies to HeapTupleSatisfiesHistoricMVCC and HeapTupleSatisfiesMVCC. I think the storage API should just leave snapshots alone. If a storage engine wants to call HeapTupleSatisfiesVisibility() with that snapshot, it can do so. Otherwise it can switch on snapshot->satisfies and handle each case however it likes. I don't see how generalizing a Snapshot for other storage engines really buys us anything except complexity and the danger of reducing performance for the existing heap. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers