[hyperman1]

I have the same impression. It solves all the autovacuum problems, but has a different set of tradeoffs, e.g. the infamous 'ORA-01555 snapshot too old' when your query tries to read the old version but it has already been cleaned away.

[sbuttgereit]

Ah the memories! Yes, the "other file" talked about in these comments is also not an unlimited resource and, depending on implementation specifics, I've found can be more limiting than the current PostgreSQL MVCC approach. In Oracle, I use to see data maintenance related procedures being written that would loop and update some large data set, but intermittently commit progress every so often... this would end up exhausting the undo availability. The more frequent the commits, the faster you'd get to the ORA-01555 before the end of the run. Not saying the procedure was right... just that the pattern was common as was the error.

Also, not too long ago PostgreSQL added Stored Procedure support... which allows for mid-transaction commits. Maybe it will be a case of "what goes around, comes around".

I should note I'm not at all against this Zheap idea, stored procedures, or multiple approaches to MVCC/storage back ends in PostgreSQL... being able to choose my effective pros/cons for a project is really desirable. But, solving the vacuum problem will create new problems.