On Mon, Aug 7, 2017 at 11:12 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Tue, Aug 1, 2017 at 1:56 PM, Haribabu Kommi <kommi.harib...@gmail.com> > wrote: > > > > > > On Sun, Jul 23, 2017 at 4:10 PM, Amit Kapila <amit.kapil...@gmail.com> > > wrote: > >> > > > >> > >> > 1. Design an API that returns values/nulls array and convert that > into a > >> > HeapTuple whenever it is required in the upper layers. All the > existing > >> > heap form/deform tuples are used for every tuple with some > adjustments. > >> > > >> > >> So, this would have the additional cost of form/deform. Also, how > >> would it have lesser changes as compare to what you have described > >> earlier? > > > > > > Yes, It have the additional cost of form/deform. It is the same approach > > that > > is described earlier. But I have an intention of modifying everywhere the > > HeapTuple is accessed. But with the other prototype changes of removing > > HeapTuple usage from triggers, I realized that it needs some clear design > > to proceed further, instead of combining those changes with pluggable > > Storage API. > > > > - heap_getnext function is kept as it as and it is used only for system > > table > > access. > > - heap_getnext_slot function is introduced to return the slot whenever > the > > data is found, otherwise NULL, This function is used in all the places > > from > > Executor and etc. > > > > - The TupleTableSlot structure is modified to contain a void* tuple > instead > > of > > HeapTuple. And also it contains the storagehanlder functions. > > - heap_insert and etc function can take Slot as an argument and perform > the > > insert operation. > > > > The cases where the TupleTableSlot is not possible to sent, form a > HeapTuple > > from the data and sent it and also note down that it is a HeapTuple data, > > not > > the tuple from the storage. > > > .. > > > > > >> > >> > 3. Design an API that returns StorageTuple(void *) but the necessary > >> > format information of that tuple can be get from the tupledesc. > wherever > >> > the tuple is present, there exists a tupledesc in most of the cases. > How > >> > about adding some kind of information in tupledesc to find out the > tuple > >> > format and call the necessary functions > >> > > > > > > > heap_getnext function returns StorageTuple instead of HeapTuple. The > tuple > > type information is available in the TupleDesc structure. > > > > All heap_insert and etc function accepts TupleTableSlot as input and > perform > > the insert operation. This approach is almost same as first approach > except > > the > > storage handler functions are stored in TupleDesc. > > > > Why do we need to store handler function in TupleDesc? As of now, the > above patch series has it available in RelationData and > TupleTableSlot, I am not sure if instead of that keeping it in > TupleDesc is a good idea. Which all kind of places require TupleDesc > to contain handler? If those are few places, can we think of passing > it as a parameter? Till now I am to able to proceed without adding any storage handler functions to TupleDesc structure. Sure, I will try the way of passing as a parameter when there is a need of it. During the progress of the patch, I am facing problems in designing the storage API regarding the Buffer. For example To replace all the HeapTupleSatisfiesMVCC and related functions with function pointers, In HeapTuple format, the tuple may belongs to one buffer, so the buffer is passed to the HeapTupleSatifisifes*** functions along with buffer, But in case of other storage formats, the single buffer may not contains the actual data. This buffer is used to set the Hint bits and mark the buffer as dirty. In case if the buffer is not available, the performance may affect for the following queries if the hint bits are not set. And also the Buffer is used to get from heap_fetch, heap_lock_tuple and related functions to check the Tuple visibility, but currently returning a buffer from the above heap_** function is not possible for other formats. And also for the HeapTuple data, the tuple data is copied into palloced buffer instead of pointing directly to the page. So, returning a Buffer is a valid or not here? Currently I am proceeding to remove the Buffer as parameter in the API and proceed further, In case if it affects the performance, we need to find out a different appraoch in handling the hint bits. comments? Regards, Hari Babu Fujitsu Australia
