Re: Unexpected VACUUM FULL failure - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Unexpected VACUUM FULL failure
Date
Msg-id 87ps1v2pd9.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Unexpected VACUUM FULL failure  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unexpected VACUUM FULL failure  (Decibel! <decibel@decibel.org>)
Re: Unexpected VACUUM FULL failure  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Another argument is that VACUUM FULL is a dinosaur that should probably
> go away entirely someday (a view I believe you share); it should
> therefore not be allowed to drive the design of other parts of the
> system.

Incidentally, every time it comes up we recommend using CLUSTER or ALTER
TABLE. And explaining the syntax for ALTER TABLE is always a bit fiddly. I
wonder if it would make sense to add a "VACUUM REWRITE" which just did the
same as the noop ALTER TABLE we're recommending people do anyways. Then we
could have a HINT from VACUUM FULL which suggests considering VACUUM REWRITE.

I would think this would be 8.4 stuff except if all we want it to do is a
straight noop alter table it's pretty trivial. The hardest part is coming up
with a name for it.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Unexpected VACUUM FULL failure
Next
From: Gregory Stark
Date:
Subject: Re: crypting prosrc in pg_proc