Tom Lane wrote:
Basically there's no free lunch: if you want the benefits of MVCC it's going to cost you somewhere. In the Postgres design you pay by having to do VACUUM pretty often for heavily-updated tables. I don't think that decision is fundamentally wrong --- the attractive thing about it is that the overhead is pushed out of the foreground query-processing code paths. We still have lots of work to do in making autovacuum smarter, avoiding vacuuming parts of relations that have not changed, and so on. But I have no desire to go over to an Oracle-style solution instead. We can't beat them by trying to be like them, and we run no small risk of falling foul of some of their patents if we do.
The question is just if it makes sense to give people the option of running some tables with a different approach where the drawbacks of the current approach are significant. This would let them stick to PostgreSQL as their one stop solution.
The MySQL storage engine plugin architecture does have some merit in general (even if you consider the rest of the RDBMS along with the available storage engines to be inferior). Some problems simply require different algorithms.
regards, Lukas ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
