On Mon, Oct 9, 2017 at 10:22 AM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote: > For me, it's crucial point that pluggable storages should be able to have > different MVCC implementation, and correspondingly have full control over > its interactions with indexes. > Thus, it would be good if we would get consensus on that point. I'd like > other discussion participants to comment whether they agree/disagree and > why. > Any comments?
I think it's good for new storage managers to have full control over interactions with indexes. I'm not sure about the MVCC part. I think it would be legitimate to want a storage manager to ignore MVCC altogether - e.g. to build a non-transactional table. I don't know that it would be a very good idea to have two different full-fledged MVCC implementations, though. Like Tom says, that would be replicating a lot of the awfulness of the MySQL model.
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.
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.
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.
------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company