6 ms·
That's amazing! Could you elaborate more on your VACUUM planning?
by marsavar 2y ago
That's amazing!
Could you elaborate more on your VACUUM planning?
- Eikon 2y agoMostly, be careful with long-running transactions (hours long), and modify your autovacuum settings to be as aggressive as possible based on your workload. Be careful with the freezing threshold too. I ran into multixact "members" limit exceeded Quite a bit when starting out :)
- whitepoplar 2y agoCan you recommend a good rule of thumb for autovacuum settings given a large workload like yours?
- Eikon 2y agoHere's mine: - autovacuum_max_workers to my number of tables (Only do so if you have enough IO capacity and CPU...). - autovacuum_naptime 10s - autovacuum_vacuum_cost_delay 1ms - autovacuum_vacuum_cost_limit 2000 You probably should read https://www.postgresql.org/docs/current/routine-vacuuming.html https://www.postgresql.org/docs/current/routine-vacuuming.ht... it's pretty well written and easy to parse!
- ahoka 2y agoDo you ever need to VACUUM FULL?
- Eikon 2y agoIt’s too slow at that scale, pg_squeeze works wonders though. I only “need” that because one of my table requires batch deletion, and I want to reclaim the space. I need to refactor that part. Otherwise nothing like that would be required.
- ahoka 2y agoYes, I was asking because you have mention deletes. Thanks for the answer, cool stuff!