Re: autovacuum_work_mem

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: autovacuum_work_mem
Дата
Msg-id 52AB5217.8060800@vmware.com
обсуждение исходный текст
Ответ на Re: autovacuum_work_mem  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: autovacuum_work_mem
Список pgsql-hackers
On 12/13/2013 08:24 PM, Bruce Momjian wrote:
> On Wed, Dec 11, 2013 at 10:35:32AM -0800, Josh Berkus wrote:
>> On 12/11/2013 09:57 AM, Robert Haas wrote:
>>> I don't agree with that assessment.  Anything that involves changing
>>> the scheduling of autovacuum is a major project that will legitimately
>>> provoke much controversy.  Extensive testing will be needed to prove
>>> that the new algorithm doesn't perform worse than the current
>>> algorithm in any important cases.  I have my doubts about whether that
>>> can be accomplished in an entire release cycle, let alone 2-3 days.
>>> In contrast, the patch proposed does something that is easy to
>>> understand, clearly safe, and an improvement over what we have now.
>>
>> +1
>>
>> There is an inherent tuning and troubleshooting challenge in anything
>> involving a feedback loop.
>
> We have avoided feedback loops in the past.  I think eventually we are
> going to need to tackle them, but it is a big job, and vacuum memory
> usage would be at the bottom of my list of feedback loop tasks.

I haven't been following this thread in detail, but would it help if we 
implemented a scheme to reduce (auto)vacuum's memory usage? Such schemes 
have been discussed in the past, packing the list of dead items more 
tightly.

I guess you'd still want to have a limit on autovacuum's memory usage. A 
much lower limit than you'd want to allow for one-off CREATE INDEX 
operations and such.

(Personally, I don't care whether we add this new option or not. And -1 
for feedback loops.)

- Heikki



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: autovacuum_work_mem
Следующее
От: Robert Haas
Дата:
Сообщение: Re: "stuck spinlock"