Re: [HACKERS] Pluggable storage

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: [HACKERS] Pluggable storage
Дата
Msg-id CAJrrPGc=bJnB78CfumpM_uNz+Sf3D4hp2tQHWw_T40jQEgv8LQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Pluggable storage  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Ответы Re: [HACKERS] Pluggable storage  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Дерево обсуждения


On Wed, Jun 28, 2017 at 1:16 PM, Haribabu Kommi <kommi.haribabu@gmail.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
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: [HACKERS] Re: [BUGS] BUG #14634: On Windows pg_basebackup should write tar tostdout in binary mode
Следующее
От: Alik Khilazhev
Дата:
Сообщение: Re: [HACKERS] [WIP] Zipfian distribution in pgbench