Re: Lock-free compaction. Why not?
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Ahmed Yarub Hani Al Nuaimi <ahmedyarubhani@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>,
Tomas Vondra <tomas.vondra@enterprisedb.com>
Date: 2024-07-21T01:52:24Z
Lists: 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
Commits
-
Support rewritten-based full vacuum as VACUUM FULL. Traditional
- 946cf229e89f 9.0.0 cited