Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit0a469c8

Browse files
committed
Remove old-style VACUUM FULL (which was known for a little while as
VACUUM FULL INPLACE), along with a boatload of subsidiary code and complexity.Per discussion, the use case for this method of vacuuming is no longer largeenough to justify maintaining it; not to mention that we don't wish to investthe work that would be needed to make it play nicely with Hot Standby.Aside from the code directly related to old-style VACUUM FULL, this commitremoves support for certain WAL record types that could only be generatedwithin VACUUM FULL, redirect-pointer removal in heap_page_prune, andnontransactional generation of cache invalidation sinval messages (the lastbeing the sticking point for Hot Standby).We still have to retain all code that copes with finding HEAP_MOVED_OFF andHEAP_MOVED_IN flag bits on existing tuples. This can't be removed as longas we want to support in-place update from pre-9.0 databases.
1 parent1ddc270 commit0a469c8

File tree

41 files changed

+276
-3766
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

41 files changed

+276
-3766
lines changed

‎doc/src/sgml/indexam.sgml

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.32 2010/01/01 21:53:49 tgl Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.33 2010/02/08 04:33:51 tgl Exp $ -->
22

33
<chapter id="indexam">
44
<title>Index Access Method Interface Definition</title>
@@ -577,11 +577,10 @@ amrestrpos (IndexScanDesc scan);
577577
The core <productname>PostgreSQL</productname> system obtains
578578
<literal>AccessShareLock</> on the index during an index scan, and
579579
<literal>RowExclusiveLock</> when updating the index (including plain
580-
<command>VACUUM</>). Since these lock
581-
types do not conflict, the access method is responsible for handling any
582-
fine-grained locking it might need. An exclusive lock on the index as a whole
583-
will be taken only during index creation, destruction,
584-
<command>REINDEX</>, or <command>VACUUM FULL</>.
580+
<command>VACUUM</>). Since these lock types do not conflict, the access
581+
method is responsible for handling any fine-grained locking it might need.
582+
An exclusive lock on the index as a whole will be taken only during index
583+
creation, destruction, or <command>REINDEX</>.
585584
</para>
586585

587586
<para>

‎doc/src/sgml/maintenance.sgml

Lines changed: 26 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.98 2010/02/03 17:25:05 momjian Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.99 2010/02/08 04:33:51 tgl Exp $ -->
22

33
<chapter id="maintenance">
44
<title>Routine Database Maintenance Tasks</title>
@@ -123,9 +123,7 @@
123123
<command>ALTER TABLE</command> while it is being vacuumed.)
124124
<command>VACUUM FULL</> requires exclusive lock on the table it is
125125
working on, and therefore cannot be done in parallel with other use
126-
of the table. Another disadvantage of <command>VACUUM FULL</> is that
127-
while it reduces table size, it does not reduce index size proportionally;
128-
in fact it can make indexes <emphasis>larger</>. Generally, therefore,
126+
of the table. Generally, therefore,
129127
administrators should strive to use standard <command>VACUUM</> and
130128
avoid <command>VACUUM FULL</>.
131129
</para>
@@ -166,13 +164,10 @@
166164
system, except in the special case where one or more pages at the
167165
end of a table become entirely free and an exclusive table lock can be
168166
easily obtained. In contrast, <command>VACUUM FULL</> actively compacts
169-
tables by moving row versions to earlier pages. It is thus able to
170-
force pages at the end of the table to become entirely free, whereupon
171-
it will return them to the operating system. However, if many rows
172-
must be moved, this can take a long time. Also, moving a row requires
173-
transiently making duplicate index entries for it (the entry pointing
174-
to its new location must be made before the old entry can be removed);
175-
so moving a lot of rows this way causes severe index bloat.
167+
tables by writing a complete new version of the table file with no dead
168+
space. This minimizes the size of the table, but can take a long time.
169+
It also requires extra disk space for the new copy of the table, until
170+
the operation completes.
176171
</para>
177172

178173
<para>
@@ -220,20 +215,19 @@
220215

221216
<tip>
222217
<para>
223-
Neither form of<command>VACUUM</>is entirely satisfactory when
218+
Plain<command>VACUUM</>may not be satisfactory when
224219
a table contains large numbers of dead row versions as a result of
225220
massive update or delete activity. If you have such a table and
226-
you need to reclaim the excess disk space it occupies, the best
227-
way is to use <xref linkend="sql-cluster" endterm="sql-cluster-title">
221+
you need to reclaim the excess disk space it occupies, you will need
222+
to use <command>VACUUM FULL</>, or alternatively
223+
<xref linkend="sql-cluster" endterm="sql-cluster-title">
228224
or one of the table-rewriting variants of
229225
<xref linkend="sql-altertable" endterm="sql-altertable-title">.
230226
These commands rewrite an entire new copy of the table and build
231-
new indexes for it. Like <command>VACUUM FULL</>, they require
232-
exclusive lock. Note that they also temporarily use extra disk
233-
space, since the old copies of the table and indexes can't be
234-
released until the new ones are complete. In the worst case where
235-
your disk is nearly full, <command>VACUUM FULL</> may be the only
236-
workable alternative.
227+
new indexes for it. All these options require exclusive lock. Note that
228+
they also temporarily use extra disk space approximately equal to the size
229+
of the table, since the old copies of the table and indexes can't be
230+
released until the new ones are complete.
237231
</para>
238232
</tip>
239233

@@ -579,22 +573,22 @@ HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
579573
<firstterm>autovacuum launcher</firstterm>, which is in charge of starting
580574
<firstterm>autovacuum worker</firstterm> processes for all databases. The
581575
launcher will distribute the work across time, attempting to start one
582-
worker on each database every <xref linkend="guc-autovacuum-naptime">
583-
seconds. One worker will be launched for each database, with a maximum
584-
of <xref linkend="guc-autovacuum-max-workers"> processes running at the
585-
same time. If there are more than
586-
<xref linkend="guc-autovacuum-max-workers"> databases to be processed,
576+
worker within each database every <xref linkend="guc-autovacuum-naptime">
577+
seconds. (Therefore, if the installation has <replaceable>N</> databases,
578+
a new worker will be launched every
579+
<varname>autovacuum_naptime</>/<replaceable>N</> seconds.)
580+
A maximum of <xref linkend="guc-autovacuum-max-workers"> worker processes
581+
are allowed to run at the same time. If there are more than
582+
<varname>autovacuum_max_workers</> databases to be processed,
587583
the next database will be processed as soon as the first worker finishes.
588584
Each worker process will check each table within its database and
589585
execute <command>VACUUM</> and/or <command>ANALYZE</> as needed.
590586
</para>
591587

592588
<para>
593-
The <xref linkend="guc-autovacuum-max-workers"> setting limits how many
594-
workers may be running at any time. If several large tables all become
595-
eligible for vacuuming in a short amount of time, all autovacuum workers
596-
might become occupied with vacuuming those tables for a long period.
597-
This would result
589+
If several large tables all become eligible for vacuuming in a short
590+
amount of time, all autovacuum workers might become occupied with
591+
vacuuming those tables for a long period. This would result
598592
in other tables and databases not being vacuumed until a worker became
599593
available. There is no limit on how many workers might be in a
600594
single database, but workers do try to avoid repeating work that has
@@ -700,8 +694,8 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
700694
</para>
701695

702696
<para>
703-
Indexpages that have become
704-
completely empty are reclaimed forre-use. However,here is stillthe possibility
697+
B-tree indexpages that have become completely empty are reclaimed for
698+
re-use. However,there is stilla possibility
705699
of inefficient use of space: if all but a few index keys on a page have
706700
been deleted, the page remains allocated. Therefore, a usage
707701
pattern in which most, but not all, keys in each range are eventually

‎doc/src/sgml/ref/vacuum.sgml

Lines changed: 13 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.57 2010/01/06 05:31:13 itagaki Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.58 2010/02/08 04:33:51 tgl Exp $
33
PostgreSQL documentation
44
-->
55

@@ -21,7 +21,7 @@ PostgreSQL documentation
2121

2222
<refsynopsisdiv>
2323
<synopsis>
24-
VACUUM [ ( { FULL[ INPLACE ]| FREEZE | VERBOSE | ANALYZE } [, ...] ) ] [ <replaceable class="PARAMETER">table</replaceable> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
24+
VACUUM [ ( { FULL | FREEZE | VERBOSE | ANALYZE } [, ...] ) ] [ <replaceable class="PARAMETER">table</replaceable> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
2525
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ <replaceable class="PARAMETER">table</replaceable> ]
2626
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">table</replaceable> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
2727
</synopsis>
@@ -58,11 +58,12 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">
5858
space and makes it
5959
available for re-use. This form of the command can operate in parallel
6060
with normal reading and writing of the table, as an exclusive lock
61-
is not obtained. <command>VACUUM
62-
FULL</command> does more extensive processing, including moving of tuples
63-
across blocks to try to compact the table to the minimum number of disk
64-
blocks. This form is much slower and requires an exclusive lock on each
65-
table while it is being processed.
61+
is not obtained. However, extra space is not returned to the operating
62+
system (in most cases); it's just kept available for re-use within the
63+
same table. <command>VACUUM FULL</command> rewrites the entire contents
64+
of the table into a new disk file with no extra space, allowing unused
65+
space to be returned to the operating system. This form is much slower and
66+
requires an exclusive lock on each table while it is being processed.
6667
</para>
6768

6869
<para>
@@ -85,27 +86,10 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">
8586
<para>
8687
Selects <quote>full</quote> vacuum, which can reclaim more
8788
space, but takes much longer and exclusively locks the table.
88-
</para>
89-
<para>
90-
For user tables, all table data and indexes are rewritten. This
91-
method requires extra disk space in which to write the new data,
92-
and is generally useful when a significant amount of space needs
93-
to be reclaimed from within the table.
94-
</para>
95-
<para>
96-
For system tables, all table data and indexes are modified in
97-
place to reclaim space. This method may require less disk space
98-
for the table data than <command>VACUUM FULL</command> on a
99-
comparable user table, but the indexes will grow which may
100-
counteract that benefit. Additionally, the operation is often
101-
slower than <command>VACUUM FULL</command> on a comparable user
102-
table.
103-
</para>
104-
<para>
105-
If <literal>FULL INPLACE</literal> is specified, the space is
106-
reclaimed in the same manner as a system table, even if it is a
107-
user table. Specifying <literal>INPLACE</literal> explicitly is
108-
rarely useful.
89+
This method also requires extra disk space, since it writes a
90+
new copy of the table and doesn't release the old copy until
91+
the operation is complete. Usually this should only be used when a
92+
significant amount of space needs to be reclaimed from within the table.
10993
</para>
11094
</listitem>
11195
</varlistentry>
@@ -217,10 +201,7 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">
217201
or updated most of the rows in a table and would like the table to
218202
physically shrink to occupy less disk space and allow faster table
219203
scans. <command>VACUUM FULL</command> will usually shrink the table
220-
more than a plain <command>VACUUM</command> would. The
221-
<option>FULL</option> option does not shrink indexes; a periodic
222-
<command>REINDEX</> is still recommended. In fact, it is often faster
223-
to drop all indexes, <command>VACUUM FULL</>, and recreate the indexes.
204+
more than a plain <command>VACUUM</command> would.
224205
</para>
225206

226207
<para>

‎doc/src/sgml/ref/vacuumdb.sgml

Lines changed: 8 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuumdb.sgml,v 1.49 2010/01/07 14:35:44 momjian Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuumdb.sgml,v 1.50 2010/02/08 04:33:51 tgl Exp $
33
PostgreSQL documentation
44
-->
55

@@ -24,7 +24,6 @@ PostgreSQL documentation
2424
<command>vacuumdb</command>
2525
<arg rep="repeat"><replaceable>connection-option</replaceable></arg>
2626
<group><arg>--full</arg><arg>-f</arg></group>
27-
<group><arg>--inplace</arg><arg>-i</arg></group>
2827
<group><arg>--freeze</arg><arg>-F</arg></group>
2928
<group><arg>--verbose</arg><arg>-v</arg></group>
3029
<group><arg>--analyze</arg><arg>-z</arg></group>
@@ -38,14 +37,12 @@ PostgreSQL documentation
3837
<arg rep="repeat"><replaceable>connection-options</replaceable></arg>
3938
<group><arg>--all</arg><arg>-a</arg></group>
4039
<group><arg>--full</arg><arg>-f</arg></group>
41-
<group><arg>--inplace</arg><arg>-i</arg></group>
4240
<group><arg>--freeze</arg><arg>-F</arg></group>
4341
<group><arg>--verbose</arg><arg>-v</arg></group>
4442
<group><arg>--analyze</arg><arg>-z</arg></group>
4543
<group><arg>--analyze-only</arg><arg>-Z</arg></group>
4644
</cmdsynopsis>
4745
</refsynopsisdiv>
48-
4946

5047
<refsect1>
5148
<title>Description</title>
@@ -60,8 +57,8 @@ PostgreSQL documentation
6057
<para>
6158
<application>vacuumdb</application> is a wrapper around the SQL
6259
command <xref linkend="SQL-VACUUM" endterm="SQL-VACUUM-title">.
63-
There is no effective difference between vacuuming and analyzing
64-
databases via this utility and via other methods for accessing the
60+
There is no effective difference between vacuuming and analyzing
61+
databases via this utility and via other methods for accessing the
6562
server.
6663
</para>
6764

@@ -73,7 +70,6 @@ PostgreSQL documentation
7370

7471
<para>
7572
<application>vacuumdb</application> accepts the following command-line arguments:
76-
7773
<variablelist>
7874
<varlistentry>
7975
<term><option>-a</option></term>
@@ -131,16 +127,6 @@ PostgreSQL documentation
131127
</listitem>
132128
</varlistentry>
133129

134-
<varlistentry>
135-
<term><option>-i</option></term>
136-
<term><option>--inplace</option></term>
137-
<listitem>
138-
<para>
139-
Perform <quote>full inplace</quote> vacuuming.
140-
</para>
141-
</listitem>
142-
</varlistentry>
143-
144130
<varlistentry>
145131
<term><option>-Z</option></term>
146132
<term><option>--analyze-only</option></term>
@@ -203,18 +189,16 @@ PostgreSQL documentation
203189
</para>
204190

205191
<para>
206-
<application>vacuumdb</application> also accepts
192+
<application>vacuumdb</application> also accepts
207193
the following command-line arguments for connection parameters:
208-
209194
<variablelist>
210195
<varlistentry>
211196
<term><option>-h <replaceable class="parameter">host</replaceable></></term>
212197
<term><option>--host <replaceable class="parameter">host</replaceable></></term>
213198
<listitem>
214199
<para>
215-
Specifies the host name of the machine on which the
216-
server
217-
is running. If the value begins with a slash, it is used
200+
Specifies the host name of the machine on which the server
201+
is running. If the value begins with a slash, it is used
218202
as the directory for the Unix domain socket.
219203
</para>
220204
</listitem>
@@ -225,7 +209,7 @@ PostgreSQL documentation
225209
<term><option>--port <replaceable class="parameter">port</replaceable></></term>
226210
<listitem>
227211
<para>
228-
Specifies the TCP port or local Unix domain socket file
212+
Specifies the TCP port or local Unix domain socket file
229213
extension on which the server
230214
is listening for connections.
231215
</para>
@@ -263,7 +247,7 @@ PostgreSQL documentation
263247
<listitem>
264248
<para>
265249
Force <application>vacuumdb</application> to prompt for a
266-
password before connecting to a database.
250+
password before connecting to a database.
267251
</para>
268252

269253
<para>

‎src/backend/access/gin/README

Lines changed: 1 addition & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
$PostgreSQL: pgsql/src/backend/access/gin/README,v 1.6 2008/07/0803:25:42 neilc Exp $
1+
$PostgreSQL: pgsql/src/backend/access/gin/README,v 1.7 2010/02/0804:33:52 tgl Exp $
22

33
Gin for PostgreSQL
44
==================
@@ -98,13 +98,6 @@ We appreciate any comments, help and suggestions.
9898
* Teach optimizer/executor that GIN is intrinsically clustered. i.e., it
9999
always returns ItemPointer in ascending order.
100100
* Tweak gincostestimate.
101-
* GIN stores several ItemPointer to heap tuple, so VACUUM FULL produces
102-
this warning message:
103-
104-
WARNING: index "idx" contains 88395 row versions, but table contains
105-
51812 row versions
106-
HINT: Rebuild the index with REINDEX.
107-
**** Workaround added
108101

109102
TODO
110103
----

‎src/backend/access/gin/ginvacuum.c

Lines changed: 3 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
* Portions Copyright (c) 1994, Regents of the University of California
99
*
1010
* IDENTIFICATION
11-
*$PostgreSQL: pgsql/src/backend/access/gin/ginvacuum.c,v 1.32 2010/01/02 16:57:33 momjian Exp $
11+
*$PostgreSQL: pgsql/src/backend/access/gin/ginvacuum.c,v 1.33 2010/02/08 04:33:52 tgl Exp $
1212
*-------------------------------------------------------------------------
1313
*/
1414

@@ -745,13 +745,9 @@ ginvacuumcleanup(PG_FUNCTION_ARGS)
745745
stats->estimated_count=info->estimated_count;
746746

747747
/*
748-
* If vacuum full, we already have exclusive lock on the index. Otherwise,
749-
* need lock unless it's local to this backend.
748+
* Need lock unless it's local to this backend.
750749
*/
751-
if (info->vacuum_full)
752-
needLock= false;
753-
else
754-
needLock= !RELATION_IS_LOCAL(index);
750+
needLock= !RELATION_IS_LOCAL(index);
755751

756752
if (needLock)
757753
LockRelationForExtension(index,ExclusiveLock);
@@ -785,15 +781,6 @@ ginvacuumcleanup(PG_FUNCTION_ARGS)
785781
}
786782
lastBlock=npages-1;
787783

788-
if (info->vacuum_full&&lastBlock>lastFilledBlock)
789-
{
790-
/* try to truncate index */
791-
RelationTruncate(index,lastFilledBlock+1);
792-
793-
stats->pages_removed=lastBlock-lastFilledBlock;
794-
totFreePages=totFreePages-stats->pages_removed;
795-
}
796-
797784
/* Finally, vacuum the FSM */
798785
IndexFreeSpaceMapVacuum(info->index);
799786

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp