From: | Decibel! <decibel(at)decibel(dot)org> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Unexpected VACUUM FULL failure |
Date: | 2007-08-10 19:24:09 |
Message-ID: | 20070810192409.GB20424@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 10, 2007 at 07:53:06PM +0100, Gregory Stark wrote:
>
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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.
One question... should we have a vacuum variant that also reindexes? Or
does that just naturally fall out of the rewrite?
BTW, rewrite sounds fine to me... anything but full, which is constantly
confused with a "full database vacuum".
--
Decibel!, aka Jim Nasby decibel(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Maier | 2007-08-10 19:30:05 | Re: Compilation of pg 7.4.17 fails on HP-UX |
Previous Message | Jonah H. Harris | 2007-08-10 19:13:15 | Re: crypting prosrc in pg_proc |