What REPACK (CONCURRENTLY) costs while it runs 0 ▲ boringSQL | Supercharge your SQL & PostgreSQL powers 1 hour ago · 17 min read3394 words · Tech · hide · 0 comments Two years ago I compared pg_repack and pg_squeeze, the two extensions most of us reach for when a table has bloated beyond what autovacuum will ever give back and VACUUM FULL isn't an option. PostgreSQL 19 changes the starting point. REPACK brings VACUUM FULL and CLUSTER together under one command, and REPACK (CONCURRENTLY) does the rewrite online. It needs no extension and no shared_preload_libraries, so it works on managed services too. That will bring online repacking to a much wider audience, so I spent the last few weeks measuring what it actually does to a running database, and how it compares with the two extensions. All data in this post comes from PostgreSQL 19beta4 (release build). The big-table tests ran on a Hetzner ccx33 (8 dedicated vCPUs, 32 GB RAM, local NVMe) and on a GCE n2-standard-4 (4 vCPUs, 16 GB RAM, pd-ssd), with pg_repack and pg_squeeze built against the same 19beta4. It's a single test table, so how the tools compare matters more than the exact times. How it… No comments yet. Log in to reply on the Fediverse. Comments will appear here.