On Thu, Oct 12, 2017 at 4:38 PM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote: > It's probably that we imply different meaning to "MVCC implementation". > While writing "MVCC implementation" I meant that, for instance, alternative > storage > may implement UNDO chains to store versions of same row. Correspondingly, > it may not have any analogue of our HOT.
Yes, the zheap project on which EnterpriseDB is working has precisely this characteristic. > However I imply that alternative storage would share our "MVCC model". So, > it > should share our transactional model including transactions, > subtransactions, snapshots etc. > Therefore, if alternative storage is transactional, then in particular it > should be able to fetch tuple with > given TID according to given snapshot. However, how it's implemented > internally is > a black box for us. Thus, we don't insist that tuple should have different > TID after update; > we don't insist there is any analogue of HOT; we don't insist alternative > storage needs vacuum > (or if even it needs vacuum, it might be performed in completely different > way) and so on.
Fully agreed.
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.
