Re: Reducing tuple overhead

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Reducing tuple overhead
Дата
Msg-id 553EA399.1010508@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Reducing tuple overhead  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Reducing tuple overhead  (Robert Haas <robertmhaas@gmail.com>)
Re: Reducing tuple overhead  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
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. This is 
actually an incredibly easy problem to have; witness how we allowed 
indexing timestamptz::date until very recently. That was clearly broken, 
but because we never attempted to re-run the index expression to do 
vacuuming at least we never corrupted the index itself.

>  > This has been discussed in the past.
>
> I have tried to search in archive, but not getting what is the exact
> problem.

Unfortunately I can't find prior discussion now either... :/
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: PL/pgSQL, RAISE and error context
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Feedback on getting rid of VACUUM FULL