On Wed, Oct 25, 2017 at 11:37 AM, Robert Haas <robertmh...@gmail.com> wrote: > 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. >
How will it switch satisfies at runtime? There are places where we might know which visibility function (*MVCC , *Dirty, etc) needs to be called, but I think there are other places (like heap_fetch) where it is not clear and we decide based on what is stored in snapshot->satisfies. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers