Re: [HACKERS] Pluggable storage
От | Haribabu Kommi |
---|---|
Тема | Re: [HACKERS] Pluggable storage |
Дата | |
Msg-id | CAJrrPGfKDHzhtgFigUywnmP5gRZ-mnU9yJ7_vbTnRJ91FZzWSQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Pluggable storage (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Pluggable storage
|
Список | pgsql-hackers |
On Fri, Oct 13, 2017 at 8:23 AM, Robert Haas <robertmhaas@gmail.com> wrote:
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.
+ amroutine->snapshot_satisfies[MVCC_VISIBILITY] = HeapTupleSatisfiesMVCC;
+ amroutine->snapshot_satisfies[SELF_VISIBILITY] = HeapTupleSatisfiesSelf;
+ amroutine->snapshot_satisfies[ANY_VISIBILITY] = HeapTupleSatisfiesAny;
+ amroutine->snapshot_satisfies[TOAST_VISIBILITY] = HeapTupleSatisfiesToast;
+ amroutine->snapshot_satisfies[DIRTY_VISIBILITY] = HeapTupleSatisfiesDirty;
+ amroutine->snapshot_satisfies[HISTORIC_MVCC_VISIBILITY] = HeapTupleSatisfiesHistoricMVCC;
+ amroutine->snapshot_satisfies[NON_VACUUMABLE_VISIBILTY] = HeapTupleSatisfiesNonVacuumable;
+
+ amroutine->snapshot_satisfiesUpdate = HeapTupleSatisfiesUpdate;
+ amroutine->snapshot_satisfiesVacuum = HeapTupleSatisfiesVacuum;
Currently no changes are carried out in snapshot logic as that is kept seperate
from storage API.
Regards,
Hari Babu
Fujitsu Australia
В списке pgsql-hackers по дате отправления: