Re: Pluggable storage

On Wed, Jun 28, 2017 at 1:16 PM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
wrote:
>
> Accepting multiple tuple format is possible with complete replacement of
> HeapTuple with TupleTableSlot or something like value/null array
> instead of a single memory chunk tuple data.
>
> Currently I am working on it to replace the HeapTuple with TupleTableSlot
> in the upper layers once the tuples is returned from the scan. In most of
> the
> places where the HeapTuple is present, either replace it with
> TupleTableSlot
> or change it to StorageTuple (void *).
>
> I am yet to evaluate whether it is possible to support as an independent
> feature
> without the need of some heap format function to understand the tuple
> format
> in every place.
>

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).

In many places while accessing system tables, the tuple is directly mapped
to
a catalog table structure and accessed. Currently I am not modifying any of
those,
and leaving them as it is until we solve all other HeapTuple replacement
problems.

In order to continue further changes in replacing the HeapTuple with
TupleTableSlot,
I am just thinking of replacing Trigger functions like plpgsql_exec_trigger
to return
TupleTableSlot instead of HeapTuple. I am thinking that these changes may
improve
the performance as it avoids the deform and forming a tuple. I am thinking
that
same TupleTableSlot memory is valid across these function calls. Am I
correct?

I am thinking that it may not possible to replace all the places of
HeapTuple with
TupleTableSlot, but it is possible with a StorageTuple (which is a void*).
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 to generate a TupleTableSlot from it and use that
from there
onward? This approach may be useful for Storing StorageTuple in
SPITupleTable
instead of TupleTableSlot.

Please let me know your comments/suggestions.

Regards,
Hari Babu
Fujitsu Australia