New VACUUM FULL
in [PgSql]
|
From: Jeff Davis on 5 Dec 2009 13:56 On Fri, 2009-12-04 at 19:49 -0500, Michael Glaesemann wrote: > > I tested a variety of situations during my review, and everything > > worked > > as I expected. > > Would there be a way for you to package the scenarios you tested into > a suite? Except for the simplest tests, they aren't easily moved to pg_regress. For instance, how do you tell if a user table's relfilenode actually changed? Easy to do manually, but tough to do with pg_regress. Regards, Jeff Davis -- 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: Tom Lane on 7 Dec 2009 01:26 Itagaki Takahiro <itagaki.takahiro(a)oss.ntt.co.jp> writes: > I added regression tests for database-wide vacuums and check changes > of relfilenodes in those commands. > ... > BTW, I needed to add ORDER BY cluase in select_views test. I didn't modify > tests in select_views at all, but database-wide vacuum moves tuples in > select_views test. I think the fix should be reasonable becausae unsorted > result set is always unstable in regression test. You should take those out again; if I am the committer I certainly will. Such a test will guarantee complete instability of every other regression test, and it's not worth it. regards, tom lane -- 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 7 Dec 2009 02:55 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > You should take those out again; if I am the committer I certainly will. > Such a test will guarantee complete instability of every other > regression test, and it's not worth it. I read the original comment was saying to add regression tests for database-wide vacuums. But I'll reduce the range of vacuum if they are not acceptable. The new patch contains only table-based vacuum for local tables and some of system tables to test non-INPLACE vacuum are not used for system tables. VACUUM FULL pg_am; VACUUM FULL pg_class; VACUUM FULL pg_database; Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
From: Takahiro Itagaki on 15 Dec 2009 04:05 Here is an updated patch rebased to the latest CVS HEAD. One remaining concern is VERBOSE. Log messages by FULL (rewrite) are less verbose than FULL INPLACE. The same can be said for CLUSTER VERBOSE, though. I don't have any plans to make CLUSTER more verbose in the patch, but "more verbose CLUSTER" could be a TODO item. =# VACUUM (FULL, VERBOSE) pgbench_accounts; INFO: vacuuming "public.pgbench_accounts" VACUUM =# VACUUM (FULL INPLACE, VERBOSE) pgbench_accounts; INFO: vacuuming "public.pgbench_accounts" INFO: "pgbench_accounts": found 0 removable, 100000 nonremovable row versions in 1640 pages DETAIL: 0 dead row versions cannot be removed yet. Nonremovable row versions range from 128 to 128 bytes long. There were 0 unused item pointers. Total free space (including removable row versions) is 195520 bytes. 0 pages are or will become empty, including 0 at the end of the table. 1 pages containing 5396 free bytes are potential move destinations. CPU 0.00s/0.01u sec elapsed 0.01 sec. INFO: index "pgbench_accounts_pkey" now contains 100000 row versions in 276 pages DETAIL: 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: "pgbench_accounts": moved 0 row versions, truncated 1640 to 1640 pages DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec. VACUUM Regards, --- Takahiro Itagaki NTT Open Source Software Center
From: Alvaro Herrera on 15 Dec 2009 08:50
Takahiro Itagaki wrote: > Here is an updated patch rebased to the latest CVS HEAD. > > One remaining concern is VERBOSE. Log messages by FULL (rewrite) are less > verbose than FULL INPLACE. The same can be said for CLUSTER VERBOSE, though. > I don't have any plans to make CLUSTER more verbose in the patch, but > "more verbose CLUSTER" could be a TODO item. Hmm. With this patch, if I do "vacuumdb -f" it will not vacuum the special system catalogs that can only be vacuumed with INPLACE, correct? If that's correct, I wonder whether it would be good to do a regular not-inplace VF for most relations, and do INPLACE for those catalogs. That way, if a sysadmin has a vacuumdb -f in crontab, it will continue to do what he expects. Maybe this is not important if Simon is able to get inplace working for all catalogs. -- 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 |