Talk about (auto)vacuum. What it is, how it works, how to configure and tune, ways to monitor and observe, tracking problems. This thought comes into mind when performance problems occur in Postgres with autovacuum being the main suspect. In my experience, stepping on this rake is quite common, and many times my colleagues and I at Data Egret bear the consequences because it will affect the performance. Looking at the vacuum itself, it seems there is not a single person who uses Postgres and never heard about vacuum. After all, vacuum has been around for some time now and there are a lot of new & old blog posts, and extensive discussions in mailing lists about it. Despite the fact that the subject of vacuum is covered in detail in the official Postgres documentation, new posts and new discussions keep popping up. Perhaps that’s why there are so many myths, legends, horror stories, and misconceptions in the “vacuum talk”. At the same time, vacuum is one of the most important parts in Postgres and database performance directly depends on correct running of vacuum. I won’t attempt to cover absolutely everything about vacuum in a single talk, however, I will go through the main points one should know when working with autovacuum, such as internals, key approaches in vacuum configurations, monitoring and performance observability, and key actions one can take in situations when vacuum is being the main suspect in all crimes, and of course, I will dispel some well-known myths and misconceptions related to autovacuum. This talk would be of interest to database administrators who would like to get a firmer grip on autovacuum processes and those who recently switched from working on commercial product to Postgres and aren’t familiar with vacuum in Postgres.