Re: [WIP] [B-Tree] Retail IndexTuple deletion

Поиск
Список
Период
Сортировка
От Kuntal Ghosh
Тема Re: [WIP] [B-Tree] Retail IndexTuple deletion
Дата
Msg-id CAGz5QC+u-PF__09DqzAVnuR25gjEpOvQu1DdePD2_FD=YMmTWw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [WIP] [B-Tree] Retail IndexTuple deletion  ("Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>)
Ответы Re: [WIP] [B-Tree] Retail IndexTuple deletion  ("Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>)
Список pgsql-hackers
On Wed, Jun 27, 2018 at 12:10 PM, Andrey V. Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
> I prepare third version of the patches. Summary:
> 1. Mask DEAD tuples at a page during consistency checking (See comments for
> the mask_dead_tuples() function).

- ItemIdSetDead(lp);
+ if (target_index_deletion_factor > 0)
+ ItemIdMarkDead(lp);
+ else
+ ItemIdSetDead(lp);
IIUC, you want to hold the storage of DEAD tuples to form the ScanKey
which is required for the index scan in the second phase of quick
vacuum strategy. To achieve that, you've only marked the tuple as DEAD
during pruning. Hence, PageRepairFragmentation cannot claim the space
for DEAD tuples since they still have storage associated with them.
But, you've WAL-logged it as DEAD tuples having no storage. So, when
the WAL record is replayed in standby(or crash recovery), the tuples
will be marked as DEAD having no storage and their space may be
reclaimed by PageRepairFragmentation. Now, if you do byte-by-byte
comparison with wal_consistency tool, it may fail even for normal
tuple as well. Please let me know if you feel the same way.

-- 
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com


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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: partition tree inspection functions
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: partition tree inspection functions