mirror of
https://git.yandere.love/skylar/pleromer-stuff.git
synced 2025-02-05 12:17:27 +00:00
19 lines
1.0 KiB
Markdown
19 lines
1.0 KiB
Markdown
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. 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. |