|From:||Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>|
|To:||Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>|
|Cc:||Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Pluggable storage|
|Views:||Raw Message | Whole Thread | Download mbox|
On Wed, Jun 28, 2017 at 1:16 PM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> 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
> places where the HeapTuple is present, either replace it with
> or change it to StorageTuple (void *).
> I am yet to evaluate whether it is possible to support as an independent
> without the need of some heap format function to understand the tuple
> in every place.
To replace tuple with slot, I took trigger and SPI calls as the first step
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
4. ItemPointerData is added as a member to the TupleTableSlot structure.
5. Modified the ExecInsert and others to work directly on TupleTableSlot
of tuple(not completely).
In many places while accessing system tables, the tuple is directly mapped
a catalog table structure and accessed. Currently I am not modifying any of
and leaving them as it is until we solve all other HeapTuple replacement
In order to continue further changes in replacing the HeapTuple with
I am just thinking of replacing Trigger functions like plpgsql_exec_trigger
TupleTableSlot instead of HeapTuple. I am thinking that these changes may
the performance as it avoids the deform and forming a tuple. I am thinking
same TupleTableSlot memory is valid across these function calls. Am I
I am thinking that it may not possible to replace all the places of
TupleTableSlot, but it is possible with a StorageTuple (which is a void*).
the tuple is present, there exists a tupledesc in most of the cases. How
adding some kind of information in tupledesc to find out the tuple format
the necessary functions to generate a TupleTableSlot from it and use that
onward? This approach may be useful for Storing StorageTuple in
instead of TupleTableSlot.
Please let me know your comments/suggestions.
|Next Message||Alik Khilazhev||2017-07-14 13:37:50||Re: [WIP] Zipfian distribution in pgbench|
|Previous Message||Heikki Linnakangas||2017-07-14 13:07:46||Re: BUG #14634: On Windows pg_basebackup should write tar to stdout in binary mode|