On Wed, Jun 28, 2017 at 12:00 AM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote:
> 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. > Yes, I agree that we need some changes in the vacuum to handle the pluggable storage. Currently I didn't fully checked the changes that are needed in vacuum, but I feel the low level changes of the function are enough, and also there should be some option from storage handler to decide whether it needs a vacuum or not? Based on this flag, the vacuum may be skipped on those tables. So these handlers no need to register those API's. Regards, Hari Babu Fujitsu Australia