开发者

Free space after massive postgres delete

开发者 https://www.devze.com 2023-02-17 09:39 出处:网络
I have a 9 million row table. I figured out that a large amount of it (around 90%) can be freed up. What actions are 开发者_如何学Goneeded after the cleanup? Vacuum, reindex etc.If you want to free up

I have a 9 million row table. I figured out that a large amount of it (around 90%) can be freed up. What actions are 开发者_如何学Goneeded after the cleanup? Vacuum, reindex etc.


If you want to free up space on the file system, either VACUUM FULL or CLUSTER can help you. You may also want to run ANALYZE after these, to make sure the planner has up-to-date statistics but this is not specifically required.

It is important to note using VACUUM FULL places an ACCESS EXCLUSIVE lock on your table(s) (blocking any operation, writes & reads), so you probably want to take your application offline for the duration.

In PostgreSQL 8.2 and earlier, VACUUM FULL is probably your best bet.

In PostgreSQL 8.3 and 8.4, the CLUSTER command was significantly improved, so VACUUM FULL is not recommended -- it's slow and it will bloat your indexes. `CLUSTER will re-create indexes from scratch and without the bloat. In my experience, it's usually much faster too. CLUSTER will also sort the whole physical table using an index, so you must pick an index. If you don't know which, the primary key will work fine.

In PostgreSQL 9.0, VACUUM FULL was changed to work like CLUSTER, so both are good.

It's hard to make predictions, but on a properly tuned server with commodity hardware, 9 million rows shouldn't take longer than 20 minutes.

  • See the documentation for CLUSTER.
  • PostgreSQL wiki about VACUUM FULL and recovering dead space


You definitely want to run a VACUUM, to free up that space for future inserts. If you want to actually reclaim that space on disk, making it available to the OS, you'll need to run VACUUM FULL. Keep in mind that VACUUM can run concurrently, but VACUUM FULL requires an exclusive lock on the table.

You will also want to REINDEX, since the indexes will remain bloated even after the VACUUM runs. If possible, a much faster way to do this is to drop the index and create it again from scratch.

You'll also want to ANALYZE, which you can just combine with the VACUUM.

See the documentation for more info.


Hi Don't it be more optimal to create a temporary table with 10% of needed records. Then drop original table and rename temporary to original ...


I'm relatively new to the world of Postgres, but I understand VACUUM ANALYZE is recommended. I think there's also a sub-option which just frees up space. I found reindex useful as well when doing batch inserts or deletes. Yes I've been working with tables with a similar number of rows, and the speed increase is very noticeable (UBuntu, Core 2 Quad)

0

精彩评论

暂无评论...
验证码 换一张
取 消