From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Huxton <dev@archonet.com>
Cc: Jason Lustig <lustig@brandeis.edu>
Cc: pgsql-performance@postgresql.org
Subject: Re: Autovacuum running out of memory
Date: Tue, 16 Oct 2007 11:38:56 -0400
Message-ID: <17244.1192549136@sss.pgh.pa.us> (raw)
In-Reply-To: <16500.1192547417@sss.pgh.pa.us>
References: <374EB3D1-EE74-4B8C-9EEC-104ADD097568@brandeis.edu>
<4714A458.5060408@archonet.com>
<E8328FA1-800E-4684-93D2-A1002BB72396@brandeis.edu>
<4714AD30.6000103@archonet.com>
<16500.1192547417@sss.pgh.pa.us>
I wrote:
> ... The weird thing about this
> is why the large maintenance_work_mem works for a regular session and
> not for autovacuum. There really shouldn't be much difference in the
> maximum workable setting for the two cases, AFAICS.
After re-reading the thread I realized that the OP is comparing manual
VACUUM FULL to automatic plain VACUUM, so the mystery is solved.
Plain VACUUM tries to grab a maintenance_work_mem-sized array of
tuple IDs immediately at command startup. VACUUM FULL doesn't work
like that.
Given the 200M ulimit -v, and the shared_buffers setting of 20000
(about 160M), the behavior is all explained if we assume that shared
memory counts against -v. Which I think it does.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, dev@archonet.com, lustig@brandeis.edu
Subject: Re: Autovacuum running out of memory
In-Reply-To: <17244.1192549136@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox