Re: Why we lost Uber as a user
От | Michael Paquier |
---|---|
Тема | Re: Why we lost Uber as a user |
Дата | |
Msg-id | CAB7nPqQOHC3213xC=Yea4TCDSDjA8rAupF_gW8mBLJubvx5z9Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Why we lost Uber as a user (Robert Haas <robertmhaas@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: