From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: New VACUUM FULL |
Date: | 2009-12-22 09:37:00 |
Message-ID: | 1261474620.7442.3948.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2009-12-22 at 18:11 +0900, Takahiro Itagaki wrote:
>
> > Old VACUUM FULL was substantially faster than this on tables that
> had
> > nothing to remove.
> Yeah, that's why traditional VACUUM FULL is still kept as INPLACE
> vacuum.
>
> > Please can you arrange for the cluster operation to skip rebuilding
> > indexes if the table is not reduced in size?
>
> Do you think we should dispose the rewritten table when we find the
> VACUUM FULL (or CLUSTER) is useless? We could save the time to
> reindex,
> but we've already consumed time to rewrite tables.
The main purpose of doing a new VF is to compact space, so its role has
slightly changed from earlier versions. We need much clearer docs about
this.
On a production system, it seems better to skip the re-indexing, which
could take a long, long time. I don't see any way to skip completely
re-writing the table though, other than scanning the table with a normal
VACUUM first, as old VF does.
I would be inclined towards the idea that if somebody does a VF of a
whole database then we should look out for and optimise for tables with
no changes, but when operating on a single table we just do as
instructed and rebuild everything, including indexes. That seems like we
should do it, but we're running out of time.
For now, I think we can easily and should skip the index build, if
appropriate. That just takes a little reworking of code, which appears
necessary anyway. We should just document that this works a little
differently now and a complete db VF is now not either necessary or a
good thing. And running
VACUUM; REINDEX DATABASE foo;
will now be very pointless.
> It will be still
> slower than VACUUM FULL INPLACE because it is read-only.
Understood, lets document that.
--
Simon Riggs www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-12-22 09:41:26 | Re: Small typos in Hot Standby docs |
Previous Message | Martin Pihlak | 2009-12-22 09:30:42 | Re: fdw validation function vs zero catalog id |