New VACUUM FULL
in [PgSql]
|
From: Simon Riggs on 12 Nov 2009 04:51 On Tue, 2009-10-27 at 13:55 +0900, Itagaki Takahiro wrote: > Here is a patch to support "rewrite" version of VACUUM FULL. > It was called "VACUUM REWRITE" in the past disucussin, > but I choose the following syntax for now: > > VACUUM ( FULL [ INPLACE | REPLACE ] ) [ table_name ] > > The reason is to contrast the new REPLACE behavior with the old INPLACE > behavior. I cannot find any good terms of opposite meaning of REWRITE. > > The new version works like as CLUSTER USING ctid or rewriting in > ALTER TABLE. It must be faster than them if we have many dead tuples > and are not interested in physical order of tuples. > > We still need traditional VACUUM FULL behavior for system catalog because > we cannot change relfilenode for them. Also, VACUUM FULL REPLACE is not > always better than traditional VACUUM FULL; the new version requires > additional disk space and might be slower if we have a few dead tuples. > > "VACUUM FULL" and "VACUUM (FULL)" are synonyms for "VACUUM (FULL REPLACE)", > but if the target table is s system catalog, instead "FULL INPLACE" is > used automatically. > If this approach is reasonable, I'll go for other supplemental parts. > (documentations, vacuumdb, etc.) Rough approach looks fine to me. The internal logic is fairly hard to read. I'd suggest you have option flags VACUUM_FULL and VACUUM_REPLACE, rather than VACUUM_INPLACE and VACUUM_REPLACE. So VACUUM_REPLACE can only be set iff VACUUM_FULL. That will reduce much of the logic. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 12 Nov 2009 08:13 Itagaki Takahiro wrote: > Here is a patch to support "rewrite" version of VACUUM FULL. > It was called "VACUUM REWRITE" in the past disucussin, > but I choose the following syntax for now: > > VACUUM ( FULL [ INPLACE | REPLACE ] ) [ table_name ] > > The reason is to contrast the new REPLACE behavior with the old INPLACE > behavior. I cannot find any good terms of opposite meaning of REWRITE. I thought the idea is to rip out the current implementation altogether. If that's the case, then it doesn't make sense to use a different syntax. Just rip the innards of VACUUM FULL and replace them with your new implementation. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 12 Nov 2009 08:17 Itagaki Takahiro wrote: > We still need traditional VACUUM FULL behavior for system catalog because > we cannot change relfilenode for them. Also, VACUUM FULL REPLACE is not > always better than traditional VACUUM FULL; the new version requires > additional disk space and might be slower if we have a few dead tuples. Tom was saying that we could fix the problem that relfilenode could not be changed by having a flat file filenode map. It would only be needed for nailed system catalogs (the rest of the tables grab their relfilenode from pg_class as usual) so it wouldn't have the problems that the previous flatfiles had (which was that they could grow too much). I don't recall if this got implemented (I don't think it did). As for it being slower with few dead tuples, I don't think this is a problem -- just use lazy vacuum in that case. I also remember we agreed on something about the need for extra disk space, but I can't remember what it was. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 12 Nov 2009 08:22 BTW I think the vacstmt.options change, which seems a reasonable idea to me, could be extracted from the patch and applied separately. That'd reduce the size of the patch somewhat. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Itagaki Takahiro on 12 Nov 2009 20:47
Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > BTW I think the vacstmt.options change, which seems a reasonable idea to > me, could be extracted from the patch and applied separately. That'd > reduce the size of the patch somewhat. It's a good idea. I separated the part into the attached patch. It replaces VacuumStmt's "vacuum", "full", "analyze", and "verbose" fields into one "options" flag field. The only user-visible change is to support "VACUUM (options)" syntax: VACUUM ( FULL, FREEZE, VERBOSE, ANALYZE ) table (columns) We don't bother with the order of options in this form :) There is a debatable issue that we can use "VACUUM (VERBOSE) table (col)" in the abobe syntax. Columns are specified but no ANALYZE option there. An ANALYZE option is added automatically in the current implementation, but we should have thrown an syntax error in such case. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center |