Re: [HACKERS] Pluggable storage - Mailing list pgsql-hackers
From | Amit Kapila |
---|---|
Subject | Re: [HACKERS] Pluggable storage |
Date | |
Msg-id | CAA4eK1JV1tnORzz-jnCXuxguQBuEUf2AJcTg2iU5QqknQU+MTw@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] Pluggable storage (Haribabu Kommi <kommi.haribabu@gmail.com>) |
Responses |
Re: [HACKERS] Pluggable storage
|
List | pgsql-hackers |
On Wed, Jul 19, 2017 at 11:33 AM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote: > > > On Sat, Jul 15, 2017 at 12:30 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> > > I am finding out that eliminating the HeapTuple usage in the upper layers > needs some major changes, How about not changing anything in the upper > layers of storage currently and just support the pluggable tuple with one of > the following approach for first version? > It is not very clear to me how any of the below alternatives are better or worse as compare to the approach you are already working. Do you mean to say that we will get away without changing all the places which take HeapTuple as input or return it as output with some of the below approaches? > 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? > 2. Design an API that returns StorageTuple(void *) with first member > represents the TYPE of the storage, so that corresponding registered > function calls can be called to deform/form the tuple whenever there is > a need of tuple. > Do you intend to say that we store such information in disk tuple or only in the in-memory version of same? Also, what makes you think that we would need hooks only for form and deform? Right now, in many cases tuple will directly point to disk page and we deal with it by retaining the pin on the corresponding buffer, what if some kinds of tuple don't follow that rule? For ex. to support in-place updates, we might always need a separate copy of tuple rather than the one pointing to disk page. > 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 > > 4. Design an API to return always the StorageTuple and it converts to > HeapTuple with a function hook if it gets registered (for heap storages > this is not required to register the hook, because it is already a HeapTuple > format). This function hook should be placed in the heap form/deform > functions. > I think some more information is required to comment on any of the approaches or suggest a new one. You might want to try by quoting some specific examples from code so that it is easy to understand what your proposal will change in that case. One idea could be that we start with some interfaces like structures TupleTableSlot, EState, HeapScanDescData, IndexScanDescData, etc. and interfaces like heap_insert, heap_update, heap_lock_tuple, SnapshotSatisfiesFunc, EvalPlanQualFetch, etc. Now, it is quite possible that we don't want to change some of these interfaces, but it can help to see how such a usage can be replaced with new kind of Tuple structure. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
pgsql-hackers by date: