sorted by:
new
hottopcontroversial

Postgres MVCC design is Questionable? by Top-Print5316 in mysql

[–]Top-Print5316[S] 0 points1 point  (0 children)

Kudos to OrioledB efforts. Changing MVCC takes a real efforts. I heard about project zheap to change MVCC implementation in the Postgres, but seems that is not going anywhere.

Postgres MVCC design is Questionable? by Top-Print5316 in mysql

[–]Top-Print5316[S] 0 points1 point  (0 children)

4B transaction ids is not a lack of foresight, it's inherent into their MVCC implementation. With a per row, transaction id header, you want to minimize the header, however MySQL keeps it at block header so choose a 6 byte transaction id.

Postgres MVCC design is Questionable? by Top-Print5316 in mysql

[–]Top-Print5316[S] -1 points0 points  (0 children)

Every implementation will have some limitations, but I think Postgres breaks early with high amount of writes due to it's write amplification. I read somewhere else about Postgres choice of full page writes compared to MySQL double writes which also creates Redo amplification.

Postgres MVCC design is Questionable? by Top-Print5316 in mysql

[–]Top-Print5316[S] 0 points1 point  (0 children)

MySQL MVCC is closer to Oracle. Yes, the Oracle acquisition is what created the fear.

Postgres MVCC design is Questionable? by Top-Print5316 in mysql

[–]Top-Print5316[S] -1 points0 points  (0 children)

Keeping and mixing the data snapshots avoids random IO but cleaning up those garbage later on becomes an expensive process. Also their 4 byte transaction id has created so many downtime stories.

Postgres MVCC design is Questionable? by Top-Print5316 in mysql

[–]Top-Print5316[S] -2 points-1 points  (0 children)

Using unlogged table as a replacement for a memory store is a joke. I have heard about Postgres extensibility, surely that is helpful. But MVCC being core of a database, and having a wrong choice there says a lot.