From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Pluggable storage |
Date: | 2017-10-12 20:38:43 |
Message-ID: | CAPpHfdtn9hbMc4+E5kKYggwg00zmyPn=FESJrbMpmhOOfhu8Hg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 11, 2017 at 11:08 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Oct 9, 2017 at 10:22 AM, Alexander Korotkov
> <a(dot)korotkov(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | legrand legrand | 2017-10-12 20:40:08 | Re: Columnar storage support |
Previous Message | Thomas Munro | 2017-10-12 20:31:12 | Re: oversight in EphemeralNamedRelation support |