Re: Feedback on getting rid of VACUUM FULL - Mailing list pgsql-hackers

From Jaime Casanova
Subject Re: Feedback on getting rid of VACUUM FULL
Date
Msg-id 3073cc9b0909161506n595db8d2q4ca812f3b37fb8e2@mail.gmail.com
Whole thread Raw
In response to Re: Feedback on getting rid of VACUUM FULL  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Wed, Sep 16, 2009 at 1:42 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 9/16/09 11:20 AM, Kevin Grittner wrote:
>> Josh Berkus <josh@agliodbs.com> wrote:
>>
>>> a) To date, I have yet to hear a single person bring up an actual
>>> real-life use-case where VACUUM FULL was desireable and REWRITE
>>> would not be.
>>
>> Would rewrite have handled this?:
>>
>> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01016.php
>
> Ok, that sounds like a real use case.
>
> However, given Heikki's post about FULL being an issue for Hot Standby,
> I'm more inclined to provide a workaround ... for example, allowing
> REWRITE to write to a designated tablespace, which would allow people to
> use a portable drive or similar for the extra disk space.
>

if you have a portable drive at hand you can create a tablespace in
that dirve, move the table to that tablespace, return to the old
tablespace and drop the new tblspc... ok, one command for all that
could be handy but not a need...

the real problem is when you *don't* have more space... i have been
recently in that situation and vaccum full was a life saver but the
only reason that server came to that situation was a horribly fsm
configuration and a bad design that forces an incredible amount of
updates...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Hot Standby 0.2.1
Next
From: Emmanuel Cecchet
Date:
Subject: Re: generic copy options