On Tue, Jun 27, 2017 at 4:19 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Jun 22, 2017 at 5:46 PM, Alexander Korotkov > <a.korot...@postgrespro.ru> wrote: > > 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? > > > > Probably, some other algorithm for vacuum. I am not sure current > vacuum with its parameters can be used so easily. One thing that > might need some thoughts is that is it sufficient to say that keep > autovacuum as off and call some different API for places where the > vacuum can be invoked manually like Vacuum command to the developer > implementing some different strategy for vacuum or we need something > more as well. What kind of other vacuum algorithm do you expect? It would be rather easier to understand if we would have examples. For me, changing of vacuum algorithm is not needed for just heap page format change. Existing vacuum algorithm could just call page format API functions for manipulating individual pages. Changing of vacuum algorithm might be needed for more invasive changes than just heap page format. However, we should first understand what these changes could be and how are they consistent with rest of API design. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
