The part of Postgres we hate the most: Multi-version concurrency control
1–10 of 148 posts
Re: The part of Postgres we hate the most: Multi-version concurrency control
#2So why Postgres chooses the worst MVCC design compared to MySQL and Oracle? Is this because of legacy reasons or other factors?
Re: The part of Postgres we hate the most: Multi-version concurrency control
#3So why Postgres chooses the worst MVCC design compared to MySQL and Oracle? Is this because of legacy reasons or other factors?
Legacy reasons. The idea was that you wouldn't need a WAL because the table itself is the log. And then you could support time-travel queries if you never cleaned up the expired tuples.
Re: The part of Postgres we hate the most: Multi-version concurrency control
#4Can the MVCC implementation be swapped via Postgres extensions?
Re: The part of Postgres we hate the most: Multi-version concurrency control
#5Can the MVCC implementation be swapped via Postgres extensions?
No. It would be a major surgery on the internals. See the article for my comment at the attempt to do this with the Zheap project:
Re: The part of Postgres we hate the most: Multi-version concurrency control
#6Can the MVCC implementation be swapped via Postgres extensions?
I think there is a new project from the Postgres community. They try to replace the storage engine to solve the inefficiency caused by MVCC
Re: The part of Postgres we hate the most: Multi-version concurrency control
#7Clever Clickbait - Of course at the end of the article they offer a solution - their product (and of course it’s AI enhanced) to the problem they have overhyped.
Re: The part of Postgres we hate the most: Multi-version concurrency control
#8Can the MVCC implementation be swapped via Postgres extensions?
Depending on the use case, I'd consider a foreign data wrapper.
Re: The part of Postgres we hate the most: Multi-version concurrency control
#9This post has a valid point. But the last line makes it clear why they care so much about it.
Yeah, table bloat and transaction ID wraparounds are terrible, but easily avoidable if you follow a few simple guidelines. Typically in my experience, best way to avoid these issues are to set sensible vacuum settings and track long running queries.
I do hate the some of the defaults in the Postgres configuration are too conservative for most workloads.
Re: The part of Postgres we hate the most: Multi-version concurrency control
#10MVCC for Amazon Redshift;
(pdf) https://www.redshiftresearchproject.org/white_papers/downloa...
(html) https://www.redshiftresearchproject.org/white_papers/downloa...
I've been told, very kindly, by a couple of people that it's the best explanation they've ever seen. I'd like to get more eyes on it, to pick up any mistakes, and it might be useful in and of itself anyway to reader, as MVCC on Redshift is I believe the same as MVCC was on Postgres before snapshot isolation.