Re: Why we lost Uber as a user
Vik Fearing <vik@2ndquadrant.fr>
From: Vik Fearing <vik@2ndquadrant.fr>
To: Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>
Cc: "Joshua D. Drake" <jd@commandprompt.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-07-27T12:52:54Z
Lists: pgsql-hackers
On 27/07/16 05:45, Robert Haas wrote: > On Tue, Jul 26, 2016 at 8:27 PM, Stephen Frost <sfrost@snowman.net> wrote: >> * Joshua D. Drake (jd@commandprompt.com) wrote: >>> Hello, >>> >>> 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. >>> >>> https://eng.uber.com/mysql-migration/ >>> >>> Specifically: >>> >>> * 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). > > Yeah. A surprising amount of that post seemed to be devoted to > describing how our MVCC architecture works rather than what problem > they had with it. I'm not saying we shouldn't take their bad > experience seriously - we clearly should - but I don't feel like it's > as clear as it could be about exactly where the breakdowns happened. There is some more detailed information in this 30-minute talk: https://vimeo.com/145842299 -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Advance backend's advertised xmin more aggressively.
- 94028691609f 9.5.0 cited
-
Improve snapshot manager by keeping explicit track of snapshots.
- 5da9da71c44f 8.4.0 cited