From 08a4fdbe2d8bb53bc624d579e052b4e74924edc1 Mon Sep 17 00:00:00 2001 From: Skylar Gasai Date: Sun, 24 Mar 2024 00:01:06 -0500 Subject: [PATCH] add notes about pg_repack remnants --- repack.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 repack.md diff --git a/repack.md b/repack.md new file mode 100644 index 0000000..4544b24 --- /dev/null +++ b/repack.md @@ -0,0 +1,25 @@ +If your database is unexpectedly large, it may be from old pg_repack remnants, which just sit there taking up space if a repack job is interrupted. + +To check if any such tables exist, run this query and look for tables named something like table_54956456 and log_9345345234, basically anything starting with table_ and log_ with a whole bunch of numbers afterwards. +``` +SELECT + relname as table_name, + pg_size_pretty(pg_total_relation_size(relid)) As "Total Size", + pg_size_pretty(pg_indexes_size(relid)) as "Index Size", + pg_size_pretty(pg_relation_size(relid)) as "Actual Size" + FROM pg_catalog.pg_statio_user_tables +ORDER BY pg_total_relation_size(relid) DESC; + +if you see shit like log_490586 and table_345345345345 in there, that's repack remnants. + +DROP EXTENSION pg_repack CASCADE; +CREATE EXTENSION pg_repack; + +``` + +To clean this up, simply drop the repack extension with the CASCADE option and re-add it to the database: +``` +DROP EXTENSION pg_repack CASCADE; +CREATE EXTENSION pg_repack; +``` +The disk space will be freed back up immediately, without the need for VACUUM FULL or REPACK. \ No newline at end of file