Re: autovacuum maintenance_work_mem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: autovacuum maintenance_work_mem
Date: 2010-11-16 17:11:17
Message-ID: 932.1289927477@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
> On Wed, Nov 17, 2010 at 01:12, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>> So for the initial implementation, we could just have each worker set
>> its local maintenance_work_mem to autovacuum_maintenance_memory / max_workers.
>> That way there's never excessive memory usage.

> It sounds reasonable, but is there the same issue for normal connections?
> We can limit max connections per user, but there are no quota for total
> memory consumed by the user. It might not be an autovacuum-specifix issue.

I agree with Itagaki-san: this isn't really autovacuum's fault.

Another objection to the above approach is that anytime you have fewer
than max_workers AV workers, you're not using the memory well. And not
using the memory well has a *direct* cost in terms of increased effort,
ie, extra indexscans. So this isn't something to mess with lightly.

I can see the possible value of decoupling autovacuum's setting from
foreground operations, though. What about creating
autovacuum_maintenance_mem but defining it as being the
maintenance_work_mem setting that each AV worker can use? If people
can't figure out that the total possible hit is maintenance_work_mem
times max_workers, their license to use a text editor should be revoked.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-11-16 17:19:53 Re: Explain analyze getrusage tracking
Previous Message Peter Eisentraut 2010-11-16 16:41:08 Re: Per-column collation