On Thu, Oct 12, 2017 at 4:38 PM, Alexander Korotkov <a.korot...@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. > During conversations with you at PGCon and other conferences I had > impression > that you share this view on pluggable storages and MVCC. Probably, we just > express > this view in different words. Or alternatively I might understand you > terribly wrong. No, it sounds like we are on the same page. I'm only hoping that we don't end with a bunch of storage engines that each use a different XID space or something icky like that. I don't think the API should try to cater to that sort of development. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
