Re: autovacuum_work_mem

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: autovacuum_work_mem
Дата
Msg-id CA+U5nMKh_Vx2NL2ktJohC03P50hsueO1fvKvWPyMqg+x4NOHBg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: autovacuum_work_mem  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: autovacuum_work_mem
Список pgsql-hackers
On 11 December 2013 17:57, Robert Haas <robertmhaas@gmail.com> wrote:

> Extensive testing will be needed to prove
> that the new algorithm doesn't perform worse than the current
> algorithm in any important cases.

Agreed, but the amount of testing seems equivalent in both cases,
assuming we weren't going to skip it for this patch.

Let me repeat the question, so we are clear...
In what circumstances will the memory usage from multiple concurrent
VACUUMs become a problem? In those circumstances, reducing
autovacuum_work_mem will cause more passes through indexes, dirtying
more pages and elongating the problem workload. I agree that multiple
concurrent VACUUMs could be a problem but this
doesn't solve that, it just makes things worse.

The *only* time this parameter would have any effect looks like when
it will make matters worse.

With considerable regret, I don't see how this solves the problem at
hand. We can and should do better.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: -d option for pg_isready is broken
Следующее
От: Gavin Flower
Дата:
Сообщение: Re: ANALYZE sampling is too good