On Thu, Oct 12, 2017 at 8:00 PM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote: > Currently I added a snapshot_satisfies API to find out whether the tuple > satisfies the visibility or not with different types of visibility routines. > I feel these > are some how enough to develop a different storage methods like UNDO. > The storage methods can decide internally how to provide the visibility. > > + amroutine->snapshot_satisfies[MVCC_VISIBILITY] = HeapTupleSatisfiesMVCC; > + amroutine->snapshot_satisfies[SELF_VISIBILITY] = HeapTupleSatisfiesSelf; > + amroutine->snapshot_satisfies[ANY_VISIBILITY] = HeapTupleSatisfiesAny; > + amroutine->snapshot_satisfies[TOAST_VISIBILITY] = HeapTupleSatisfiesToast; > + amroutine->snapshot_satisfies[DIRTY_VISIBILITY] = HeapTupleSatisfiesDirty; > + amroutine->snapshot_satisfies[HISTORIC_MVCC_VISIBILITY] = > HeapTupleSatisfiesHistoricMVCC; > + amroutine->snapshot_satisfies[NON_VACUUMABLE_VISIBILTY] = > HeapTupleSatisfiesNonVacuumable; > + > + amroutine->snapshot_satisfiesUpdate = HeapTupleSatisfiesUpdate; > + amroutine->snapshot_satisfiesVacuum = HeapTupleSatisfiesVacuum; > > Currently no changes are carried out in snapshot logic as that is kept > seperate > from storage API.
That seems like a strange choice of API. I think it should more integrated with the scan logic. For example, if I'm doing an index scan, and I get a TID, then I should be able to just say "here's a TID, give me any tuples associated with that TID that are visible to the scan snapshot". Then for the current heap it will do heap_hot_search_buffer, and for zheap it will walk the undo chain and return the relevant tuple from the chain.
OK, Understood.
I will check along these lines and come up with storage API's.
