From: Anton Melser <melser.anton@gmail.com>
To: Heikki Linnakangas <heikki@enterprisedb.com>
Cc: Bruce McAlister <bruce.mcalister@blueface.ie>
Cc: pgsql-performance@postgresql.org
Subject: Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
Date: Tue, 13 Mar 2007 23:20:38 +0100
Message-ID: <92d3a4950703131520x27de4cc2w4780d0700cf606e2@mail.gmail.com> (raw)
In-Reply-To: <45EC2CCF.8020906@enterprisedb.com>
References: <esh2mg$16vu$1@news.hub.org>
<45EC1931.3020701@enterprisedb.com>
<esh858$2iiv$1@news.hub.org>
<45EC2CCF.8020906@enterprisedb.com>
> In fact, getting rid of vacuum full, or changing it to work like
> cluster, has been proposed in the past. The use case really is pretty
> narrow; cluster is a lot faster if there's a lot of unused space in the
> table, and if there's not, vacuum full isn't going to do much so there's
> not much point running it in the first place. The reason it exists is
> largely historical, there hasn't been a pressing reason to remove it either.
I can assure you it is a great way to get back gigabytes when someone
has put no vacuum strategy in place and your 200K row table (with
about 200 bytes per row) is taking up 1.7gig!!!
Vive le truncate table, and vive le vacuum full!
:-)
Anton
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: melser.anton@gmail.com, heikki@enterprisedb.com, bruce.mcalister@blueface.ie
Subject: Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
In-Reply-To: <92d3a4950703131520x27de4cc2w4780d0700cf606e2@mail.gmail.com>
* 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