Re: Reducing tuple overhead

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Reducing tuple overhead
Дата
Msg-id CAA4eK1Khu958CUGhOstF5gYCy7Tywj6e3Xokv67b-DkihxNgYw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Reducing tuple overhead  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Reducing tuple overhead  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Apr 28, 2015 at 2:31 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>
> On 4/25/15 12:12 AM, Amit Kapila wrote:
>>
>>  > ... which isn't possible. You can not go from a heap tuple to an
>> index tuple.
>>
>> We will have the access to index value during delete, so why do you
>> think that we need linkage between heap and index tuple to perform
>> Delete operation?  I think we need to think more to design Delete
>> .. by CTID, but that should be doable.
>
>
> The problem with just having the value is that if *anything* changes between how you evaluated the value when you created the index tuple and when you evaluate it a second time you'll corrupt your index. 
>

I think I am missing something here, but when this second
evaluation is needed.  Basically what I understand from index
insertion is that it evaluates the value to be inserted in index
before calling nbtree module and then nbtree just inserts the
value/tuple passed to it.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: Sawada Masahiko
Дата:
Сообщение: Re: Auditing extension for PostgreSQL (Take 2)
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: Final Patch for GROUPING SETS