On Tue, Jun 13, 2017 at 4:50 AM, Haribabu Kommi <kommi.harib...@gmail.com> wrote:
> On Fri, Oct 14, 2016 at 7:26 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: > >> I have sent the partial patch I have to Hari Babu Kommi. We expect that >> he will be able to further this goal some more. > > > Thanks Alvaro for sharing your development patch. > > Most of the patch design is same as described by Alvaro in the first mail > [1]. > I will detail the modifications, pending items and open items (needs > discussion) > to implement proper pluggable storage. > > Here I attached WIP patches to support pluggable storage. The patch series > are may not work individually. Still so many things are under development. > These patches are just to share the approach of the current development. > > Some notable changes that I did to make the patch work: > > 1. Added storageam handler to the slot, this is because not all places > the relation is not available in handy. > 2. Retained the minimal Tuple in the slot, as this is used in HASH join. > As per the first version, I feel it is fine to allow creating HeapTuple > format data. > > Thanks everyone for sharing their ideas in the developer's unconference at > PGCon Ottawa. > > Pending items: > > 1. Replacement of Tuple with slot in Trigger functionality > 2. Replacement of Tuple with Slot from storage handler functions. > 3. Remove/minimize the use of HeapTuple as a Datum. > 4. Replace all references of HeapScanDesc with StorageScanDesc > 5. Planner changes to consider the relation storage during the planning. > 6. Any planner changes based on the discussion of open items? > 7. some Executor changes to consider the storage advantages? > > Open Items: > > 1. The BitmapHeapScan and TableSampleScan are tightly coupled with > HeapTuple and HeapScanDesc, So these scans are directly operating > on those structures and providing the result. > What about vacuum? I see vacuum is untouched in the patchset and it is not mentioned in this discussion. Do you plan to override low-level function like heap_page_prune(), lazy_vacuum_page() etc., but preserve high-level logic of vacuum? Or do you plan to let pluggable storage implement its own high-level vacuum algorithm? ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
