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