Re: Lock-free compaction. Why not?

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Lock-free compaction. Why not?
Дата
Msg-id CAApHDvpuuHhrY8+5m4K6nXyTarEVaD44kRJg3tZ4XpMawqfijA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Lock-free compaction. Why not?  (Ahmed Yarub Hani Al Nuaimi <ahmedyarubhani@gmail.com>)
Ответы Re: Lock-free compaction. Why not?
Re: Lock-free compaction. Why not?
Список pgsql-hackers
On Sun, 21 Jul 2024 at 04:00, Ahmed Yarub Hani Al Nuaimi
<ahmedyarubhani@gmail.com> wrote:
> 2- Can you point me to a resource explaining why this might lead to index bloating?

No resource links, but if you move a tuple to another page then you
must also adjust the index.  If you have no exclusive lock on the
table, then you must assume older transactions still need the old
tuple version, so you need to create another index entry rather than
re-pointing the existing index entry's ctid to the new tuple version.
It's not hard to imagine that would cause the index to become larger
if you had to move some decent portion of the tuples to other pages.

FWIW, I think it would be good if we had some easier way to compact
tables without blocking concurrent users.  My primary interest in TID
Range Scans was to allow easier identification of tuples near the end
of the heap that could be manually UPDATEd after a vacuum to allow the
heap to be shrunk during the next vacuum.

David



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Add mention of execution time memory for enable_partitionwise_* GUCs
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: pg_upgrade and logical replication