Re: autovacuum_work_mem

On 11 December 2013 19:54, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 12/11/2013 11:37 AM, Simon Riggs wrote:> On 11 December 2013 17:57,
> Robert Haas <robertmhaas(at)gmail(dot)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.
>
> No performance testing is required for this patch. The effect of memory
> limits on vacuum are already well-known and well-understood.

Yes, I wrote the patch that you use to tune autovacuum. Not everybody
agreed with me then either about whether we need it, so I'm used to
people questioning my thinking and am happy people do.

>> With considerable regret, I don't see how this solves the problem at
>> hand. We can and should do better.
>
> I strongly disagree. The problem we are dealing with currently is that
> two resource limits which should have *always* been independent of each
> other are currently conflated into a single GUC variable. This forces
> users to remember to set maintenance_work_mem interactively every time
> they want to run a manual VACUUM, because the setting in postgresql.conf
> is needed to tune autovacuum.

I understand the general argument and it sounds quite cool, I agree. I
am all for user control.

But nobody has given a sensible answer to my questions, other than to
roll out the same general points again. In practice, its a knob that
does not do very much of use for us. At best it is addressing the
symptoms, not the cause. IMHO.

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