VACUUM sucks...
Conversation
Ok, InnoDB is cool but... let's try another one with same open source license and same language than PostgreSQL.... YugabyteDB?
1
Not manual or scheduled. The storage engine (based on RocksDB) does a lot of things in background. Writes go to provisional records, are applied later to an insert-only store where time is part of the key, cleanup is done on reads, or LSM-Tree SSTable background compaction
1
1
2
All this is not an answer to problem of course. Just side ideas about MVCC implementations. I've never recommended to change the engine without knowing exactly the issue. Vacuum has been enhanced a lot in recent PostgreSQL releases.
1
1
And yet it sucks.
And autovacuum sucks automatically.
P.S. I don't have any problems -- not today.
1
1
VACUUM unnecessarily couples tasks (e.g., pruning, freezing, index stuff). If we didn't have to freeze then we wouldn't have to prune (first heap pass cleanup) on any particular timeline - we could choose to be very lazy. Simplicity through decoupling is the answer long term IMV.
"If a tree falls in a forest and no one is around to hear it, does it make a sound?" - it's all a matter of perspective. Same with dead tuples: they can be "conceptually deleted" (not just conceptually dead) without being physically deleted. The difference often won't matter.
1