* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> The following article is a very good look at some of our limitations
> and highlights some of the pains many of us have been working
> "around" since we started using the software.
> * Inefficient architecture for writes
> * Inefficient data replication
The above are related and there are serious downsides to having an extra
mapping in the middle between the indexes and the heap.
What makes me doubt just how well they understood the issues or what is
happening is the lack of any mention of hint bits of tuple freezing
(requiring additional writes).
> * Issues with table corruption
That was a bug that was fixed quite quickly once it was detected. The
implication that MySQL doesn't have similar bugs is entirely incorrect,
as is the idea that logical replication would avoid data corruption
issues (in practice, it actually tends to be quite a bit worse).
> * Poor replica MVCC support
Solved through the hot standby feedback system.
> * Difficulty upgrading to newer releases
Their specific issue with these upgrades was solved, years ago, by me
(and it wasn't particularly difficult to do...) through the use of
pg_upgrade's --link option and rsync's ability to construct hard link
trees. Making major release upgrades easier with less downtime is
certainly a good goal, but there's been a solution to the specific issue
they had here for quite a while.
In response to
pgsql-hackers by date
|Next:||From: Andres Freund||Date: 2016-07-27 00:43:33|
|Subject: Macro customizable hashtable / bitmapscan & aggregation perf|
|Previous:||From: David Fetter||Date: 2016-07-27 00:22:01|
|Subject: Re: PoC: Make it possible to disallow WHERE-less UPDATE