Re: [HACKERS] Pluggable storage
| От | Haribabu Kommi |
|---|---|
| Тема | Re: [HACKERS] Pluggable storage |
| Дата | |
| Msg-id | CAJrrPGfY4ibJDJNqvj1Kd06RT-MTY+B8NWr41J7PM-nM156Wug@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Pluggable storage (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [HACKERS] Pluggable storage
(Amit Kapila <amit.kapila16@gmail.com>)
|
| Список | pgsql-hackers |
On Sat, Jul 15, 2017 at 12:30 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Jul 14, 2017 at 8:35 AM, Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
> To replace tuple with slot, I took trigger and SPI calls as the first step
> in modifying
> from tuple to slot, Here I attached a WIP patch. The notable changes are,
>
> 1. Replace most of the HeapTuple with Slot in SPI interface functions.
> 2. In SPITupleTable, Instead of HeapTuple, it is changed to TupleTableSlot.
> But this change may not be a proper approach, because a duplicate copy of
> TupleTableSlot is generated and stored.
> 3. Changed all trigger interfaces to accept TupleTableSlot Instead of
> HeapTuple.
> 4. ItemPointerData is added as a member to the TupleTableSlot structure.
> 5. Modified the ExecInsert and others to work directly on TupleTableSlot
> instead
> of tuple(not completely).
What problem are you trying to solve with these changes? I'm not
saying that it's a bad idea, but I think you should spell out the
motivation a little more explicitly.
Sorry for not providing complete details. I am trying these experiments
to find out the best way to return the tuple from Storage methods by
designing a proper API.
The changes that I am doing are to reduce the dependency on the
HeapTuple format with value/nulls array. So if there is no dependency
on the HeapTuple format in the upper layers of the PostgreSQL storage,
then directly we can define the StorageAPI to return the value/nulls array
instead of one big chunck of tuple data like HeapTuple or StorageTuple(void *).
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?
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.
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.
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.
Any other better ideas for a first version.
Regards,
Hari Babu
Fujitsu Australia
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Mark DilgerДата:
Сообщение: Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
Следующее
От: Masahiko SawadaДата:
Сообщение: Re: [HACKERS] merge psql ef/ev sf/sv handling functions