zlacker

>>andren+(OP)
This post has a valid point. But the last line makes it clear why they care so much about it.

Yeah, table bloat and transaction ID wraparounds are terrible, but easily avoidable if you follow a few simple guidelines. Typically in my experience, best way to avoid these issues are to set sensible vacuum settings and track long running queries.

I do hate the some of the defaults in the Postgres configuration are too conservative for most workloads.

>>sppras+Ul
What last line? The literal last line is "We’ll cover more about what we can do in our next article."

Do you mean this one?

> At OtterTune, we see this problem often in our customers’ databases. One PostgreSQL RDS instance had a long-running query caused by stale statistics after bulk insertions. This query blocked the autovacuum from updating the statistics, resulting in more long-running queries. OtterTune’s automated health checks identified the problem, but the administrator still had to kill the query manually and run ANALYZE after bulk insertions. The good news is that the long query’s execution time went from 52 minutes to just 34 seconds.