On Wed, Oct 11, 2017 at 11:08 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Oct 9, 2017 at 10:22 AM, Alexander Korotkov > <a.korot...@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