Re: Pluggable storage

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pluggable storage
Date: 2017-10-31 09:59:30
Message-ID: CAJrrPGf17rSrM_uonLpASZ3d3nLSWTPj_TD5S8yQc6OkVS2=VA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Fri, Oct 27, 2017 at 4:06 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Oct 25, 2017 at 1:59 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> >> Another thing to consider is that, if we could replace satisfiesfunc,
> >> it would probably break some existing code. There are multiple places
> >> in the code that compare snapshot->satisfies to
> >> HeapTupleSatisfiesHistoricMVCC and HeapTupleSatisfiesMVCC.
> >>
> >> I think the storage API should just leave snapshots alone. If a
> >> storage engine wants to call HeapTupleSatisfiesVisibility() with that
> >> snapshot, it can do so. Otherwise it can switch on
> >> snapshot->satisfies and handle each case however it likes.
> >>
> >
> > How will it switch satisfies at runtime? There are places where we
> > might know which visibility function (*MVCC , *Dirty, etc) needs to be
> > called, but I think there are other places (like heap_fetch) where it
> > is not clear and we decide based on what is stored in
> > snapshot->satisfies.
>
> An alternative storage engine needs to provide its own implementation
> of heap_fetch, and that replacement implementation can implement MVCC
> and other snapshot behavior in any way it likes.

In the current set of patches, I changed the snapshot->satisfies function
point to an enum type, Based on the snapshot visibility type, internally
the storage AM will call the corresponding visibility function.

Additional changes that are done in the patches compared to earlier
patches apart from rebase.

0004-Adding tuple visibility:

Tuple visibility API functions are reduced to 3. It still needs further
optimization.

Tuple satisfies visibility check is added to heap function that don't have
currently.

0006-tuple-insert

Move the index tuple insertion logic inside storage Am with a function
pointer, applicable to insert and updates. yet to handle the insert index
tuples
for multi insert scenario.

Removed the speculative finish API. Yet to remove abort API.

Known pending items:

1. Provide a generic new API like heap_fetch to remove heap_hot_search
and visibility functions usage.
2. Move toast table details into storage AM, Toast method depends on
storage.
and also toast flattening function needs to be replaced with some generic
functions.
3. Provide new API to get the heaptuple from index or building the index.
may be the same API like heap_fetch may satisfy this requirement also.
4. Bulk insert functionality needs a separate API to deal with all storage
AMs.
5. Provide a framework to add reloptions based on storage.
6. Needs a generic API to support rewrite the heap, (cluster command)

Regards,
Hari Babu
Fujitsu Australia

Attachment Content-Type Size
0007-Scan-functions-are-added-to-storage-AM.patch application/octet-stream 181.3 KB
0008-Remove-HeapScanDesc-usage-outside-heap.patch application/octet-stream 92.4 KB
0001-Change-Create-Access-method-to-include-storage-handl.patch application/octet-stream 9.3 KB
0002-Storage-AM-API-hooks-and-related-functions.patch application/octet-stream 18.7 KB
0003-Adding-storageam-hanlder-to-relation-structure.patch application/octet-stream 7.0 KB
0004-Adding-tuple-visibility-function-to-storage-AM.patch application/octet-stream 148.6 KB
0005-slot-hooks-are-added-to-storage-AM.patch application/octet-stream 62.7 KB
0006-Tuple-Insert-API-is-added-to-Storage-AM.patch application/octet-stream 261.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-10-31 10:07:50 Re: [bug fix] postgres.exe crashes with access violation on Windows while starting up
Previous Message Kyotaro HORIGUCHI 2017-10-31 09:49:37 Re: More stats about skipped vacuums