bronze/pleromer-stuff
1
0
Fork 0
mirror of https://git.yandere.love/skylar/pleromer-stuff.git synced 2024-11-12 20:36:04 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

add notes about pg_repack remnants

Browse Source
This commit is contained in:
Skylar Gasai 2024-03-24 00:01:06 -05:00
parent 558229e55c
commit 08a4fdbe2d
1 changed files with 25 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
repack.md Normal file
View File

@ -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.