Re: [HACKERS] Pluggable storage
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Pluggable storage |
Дата | |
Msg-id | CA+TgmobCu9tf8+XBi3S2dQnN=PhE72vE1ztrt8P+X14Uw=W=cA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Pluggable storage (Haribabu Kommi <kommi.haribabu@gmail.com>) |
Ответы |
Re: [HACKERS] Pluggable storage
|
Список | pgsql-hackers |
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. 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
В списке pgsql-hackers по дате отправления: