Re: Why we lost Uber as a user
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Josh Berkus <josh@agliodbs.com>, "Joshua D. Drake" <jd@commandprompt.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-07-26T22:58:03Z
Lists: pgsql-hackers
On Wed, Jul 27, 2016 at 7:19 AM, Robert Haas <robertmhaas@gmail.com> wrote: > I've seen multiple cases where this kind of thing causes a > sufficiently large performance regression that the system just can't > keep up. Things are OK when the table is freshly-loaded, but as soon > as somebody runs a query on any table in the cluster that lasts for a > minute or two, so much bloat accumulates that the performance drops to > an unacceptable level. This kind of thing certainly doesn't happen to > everybody, but equally certainly, this isn't the first time I've heard > of it being a problem. Sometimes, with careful tending and a very > aggressive autovacuum configuration, you can live with it, but it's > never a lot of fun. Yes.. That's not fun at all. And it takes days to do this tuning properly if you do such kind of tests on a given product that should work the way its spec certifies it to ease the customer experience. As much as this post is interesting, the comments on HN are a good read as well: https://news.ycombinator.com/item?id=12166585 Some points raised are that the "flaws" mentioned in this post are actually advantages. But I guess this depends on how you want to run your business via your application layer. -- Michael
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