On Fri, Jul 14, 2017 at 8:35 AM, Haribabu Kommi <kommi.harib...@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. I think performance is likely to be a key concern here. Maybe these interfaces are Just Better with TupleTableSlots and the patch is a win regardless of pluggable storage -- but if the reverse turns out to be true, and this slows things down in cases that anyone cares about, I think that's going to be a problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
