Re: autovacuum_work_mem - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: autovacuum_work_mem
Date
Msg-id CA+U5nMKh_Vx2NL2ktJohC03P50hsueO1fvKvWPyMqg+x4NOHBg@mail.gmail.com
Whole thread Raw
In response to Re: autovacuum_work_mem  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: autovacuum_work_mem
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: -d option for pg_isready is broken
Next
From: Gavin Flower
Date:
Subject: Re: ANALYZE sampling is too good