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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Why we lost Uber as a user
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: pg_dumping extensions having sequences with 9.6beta3