All Products
Search
Document Center

PolarDB:Garbage collection mechanism

Last Updated:Mar 28, 2026

PolarDB for PostgreSQL (Compatible with Oracle) uses VACUUM to reclaim storage space occupied by dead tuples. Reclaimed space is not returned to the operating system—it stays available for reuse by newly inserted or updated rows in the same table.

Garbage collection mechanism

In the diagram, tuple1 and tuple2 are valid rows, and unused represents invalid rows (dead tuples). After garbage collection, the space occupied by dead tuples is released and can be reused.

How it works

PolarDB for PostgreSQL (Compatible with Oracle) implements multiversion concurrency control (MVCC) by maintaining multiple row versions. Every UPDATE or DELETE operation creates a new row version and marks the previous version as invalid. These invalid versions—dead tuples—accumulate in data blocks and must be reclaimed regularly. If not cleared in time, dead tuples cause table bloat.

Garbage collection is triggered automatically when the number of dead tuples exceeds a calculated threshold:

autovacuum threshold = autovacuum_vacuum_scale_factor * total_rows + autovacuum_vacuum_threshold

For example, with default settings (autovacuum_vacuum_scale_factor = 0.2, autovacuum_vacuum_threshold = 50), a table with 100 rows triggers autovacuum when dead tuples exceed 70 (0.2 * 100 + 50). Both parameters are configurable.

VACUUM runs in the background and does not block concurrent reads or writes. To trigger garbage collection immediately on a specific table, run:

VACUUM <table_name>;