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
> "But making sure that PostgreSQL’s autovacuum is running as best as possible is difficult due to its complexity."

The problem, as the article states it, is that a "sensible" vacuum setting for one table is a terrible setting for another depending on how large these tables are. On a 100 million tuple table you'd be waiting 'til there there were 20 million garbage tuples before taking action.

>>spudly+MZ
You can set autovacuum reloptions on a per-table basis, if they differ that much for your your use case.