Postgres 19's REPACK CONCURRENTLY trades VACUUM FULL's table lock for a 3.8x rise in average insert latency

The two latency numbers measure different things, so take them apart. The average insert took about 3.8 times as long during the repack ^[14]. The slowest insert, at 63 ms ^[4], was about 11 times that raised average ^[15]. The post reports only a mean and a maximum, with nothing on the middle of the distribution and no figure for the loop's insert rate.

Writers are not blocked. Their changes are decoded through a replication slot by a background worker and replayed just before the files are swapped ^[6]. That is where the extra time can come from: every row the insert loop adds during the copy is a row that worker has to decode and replay.

Set that against the lock. In the post's demo, a long-running report that touched the table and has not committed ^[13] sits ahead of the VACUUM FULL request. The post says one ACCESS EXCLUSIVE request at the front of the line makes everything behind it wait ^[12]. In our view, a few milliseconds on each insert is a fair price against that queue, for a table that has to stay writable and a write path with headroom.

For the number to transfer, your row width, insert rate and hardware would all have to resemble depesz's, and the post describes neither his hardware nor his row width. The run used the PostgreSQL 19 development branch in April ^[1], not a release.

Extension users will recognise the design. According to CYBERTEC, pg_repack creates a set of triggers on the table, and its own pg_squeeze uses logical decoding instead ^[10]. The core command follows the second approach. The reported figures cover REPACK CONCURRENTLY alone, so whether it is cheaper for writers than either extension is untested here.

The release notes explain the rename: "The two former commands did similar things, but with confusing names, so unify them as REPACK. The old commands have been retained for compatibility." ^[11]