DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com;
 h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
 b=lCG6nABgGtZzKo7UqHNY68lX+Yd5P9kA52gyb87C8wrH+TvcdXS6owM0c95QmE1/+b72zH9tSkf3tZKRo7VhtaoaIU5hXYwcPUKcyZiD2Re70BgfobZUExh08m/5Pi+DGsV5zX5yuhLUjCj/9YA4GoOJRrJTwPWGgJa6YRgTxCo=;
References: <535715181.700956.1378223895627.JavaMail.root@trovaprezzi.it>
 <441706222.701556.1378224973704.JavaMail.root@trovaprezzi.it>
 <1378240470.79541.YahooMailNeo@web162905.mail.bf1.yahoo.com>
 <1680047223.718929.1378275308275.JavaMail.root@trovaprezzi.it>
Message-ID: <1378282241.27940.YahooMailNeo@web162905.mail.bf1.yahoo.com>
Date: Wed, 4 Sep 2013 01:10:41 -0700 (PDT)
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: COPY TO and VACUUM
To: Roberto Grandi <roberto.grandi@trovaprezzi.it>
Cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
In-Reply-To: <1680047223.718929.1378275308275.JavaMail.root@trovaprezzi.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Roberto Grandi <roberto.grandi@trovaprezzi.it> wrote:

> we are using postgres 8.3.

> my scenario is:
>
> - Delete all products record for a vendor
> - Reload all products record (from new listing) for the same
>=A0=A0 vendor.
>
> Obviously we repeat this process continously and table space is
> growing really fast.
>
> Can you suggest me an approach for autovacuum within this
> scenario and, if you want, suggest me an appropriate version of
> postgres that help solving my problem?

At this point I would recommend the latest minor release of 9.2 for
production use.=A0 If you were early in a development cycle I would
suggest considering the soon-to-be-released 9.3.0.=A0 Be sure to stay
current on minor releases.

http://www.postgresql.org/support/versioning/

If your table space is growing fast with this usage pattern, it
suggests that autovacuum is not configured to be aggressive enough.
My suggestions:

Make sure autovacuum is on.

Decrease autovacuum_naptime to 15s, so that it will notice deletes
sooner.

You could consider reducing autovacuum_scale_factor below the
default of 0.2 so that it triggers based on fewer deletes.

You should probably set autovacuum_vacuum_cost_limit to 400 and
incrementally increase it until autovacuum is able to keep up with
the activity you describe.=A0 It defaults to 200 and I have had to
set it to 650 on some systems to allow it to keep up.=A0 It wouldn't
be surprising if some systems need a higher setting.=A0 Higher
settings may cause autovacuum activity to have a more noticeable
impact on foreground processes; but if it is too low, you will
develop bloat which will harm performance and eat disk space.

If all autovacuum workers are sometimes busy with big tables for
extended periods and you see other tables neglected for too long,
you should boost autovacuum_max_workers until that problem is
solved.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--=20
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance