Do or undo – there is no VACUUM

This proposal seems like it would do away with that feature - but perhaps it's a good trade off in practice. I wonder what people here think.

Which makes me think: Maybe the true reason Postgres does it differently isn‘t technical but legal. Could there be a patent?

Like, this is how I read this article: "PostgreSQL does something one way, which everyone is used to, and it is clearly pretty stupid; we have an entirely new way of thinking about this that we are pretty sure--but not 100% sure as we aren't that arrogant--will be better than the way it is happening now: we will just do this, this, and this, which certainly seems better. more to come!".

The article I would have wanted to see: "it is well known in the world of database software that there are two ways of doing this one thing, and PostgreSQL is pretty unique in doing it this way which we know has some downsides, such as this, this, and this; of course, the other way also has known downsides, such as this, this, and this; we started to ask ourselves if it would still make sense to try that model for some workloads against PostgreSQL".

Essentially, a good version of this article would have at least mentioned why MVCC is interesting at all (as this article skirts dangerously close to "clearly we should just update everything in place"). It would have talked about the advantages of delaying write amplification vs. doing two writes immediately. It would have talked about Heap-Only-Tuples as a form of garbage collection on that write amplification. It would have talked about reasons why people would opt to have lower than 100% fillfactor on a table even if they weren't storing multiple tuple copies. It would have talked about snapshot serializability and predicate locking and how they are designed around MVCC and aaked of those still made sense if implemented using an undo log. It would have admitted that most other databases do it the other way, and asked "why didn't PostgreSQL"?

This article barely even went into the primary advnatage of the scheme they are describing, which is that if you have a million indexes on a table you don't have to update all of them. Seriously: the reason to care about this has nothing to do with the VACUUM cost as if you sit down with a pencil for a moment it should be obvious that if you have to do two writes now vs. one write now and one write later you have only lost flexibility in scheduling your maintenance. People get burned by VACUUM due to bad planning for later capacity needs when they least expect it, not due to the raw amplification. But the index issue? That is serious. They didn't talk about the index issue as the article was supposedly already too long, but... the article didn't really say anything.

""" We at EnterpriseDB are intending to try implementing the MySQL InnoDB undo log technique in PostgreSQL to see if it offers meaningful benefits vs. having to do a later VACUUM as we currently have to do; wish us luck! For more information on undo logging, please read the following articles.

https://dev.mysql.com/doc/refman/5.7/en/innodb-undo-logs.htm... https://mariadb.com/kb/en/library/undo-log/ https://blog.jcole.us/2014/04/16/the-basics-of-the-innodb-un... """

^ This entire article is just saying exactly this.

In the end, this article is frankly leading to more confusion than clarity :/. It has people here asking if PostgreSQL did it this way due to patents, and assuming that the simplistic idea that "if 50% of your statements commit then this is a win" is correct. The article even starts with a totally misleading concept for how much table bloat you are going to end up with: it isn't 50% after the first VACUUM (which you should be doing pretty quickly). I guess I don't even understand why this article was published today.