{
    "content": [
        {
            "type": "text",
            "text": "# VACUUM (man)\n\n**Summary:** VACUUM - garbage-collect and optionally analyze a database\n\n**Synopsis:** VACUUM [ ( option [, ...] ) ] [ tableandcolumns [, ...] ]\nVACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ tableandcolumns [, ...] ]\nwhere option can be one of:\nFULL [ boolean ]\nFREEZE [ boolean ]\nVERBOSE [ boolean ]\nANALYZE [ boolean ]\nDISABLEPAGESKIPPING [ boolean ]\nSKIPLOCKED [ boolean ]\nINDEXCLEANUP { AUTO | ON | OFF }\nPROCESSTOAST [ boolean ]\nTRUNCATE [ boolean ]\nPARALLEL integer\nand tableandcolumns is:\ntablename [ ( columnname [, ...] ) ]\n\n## Examples\n\n- `To clean a single table onek, analyze it for the optimizer and print a detailed vacuum`\n- `activity report:`\n- `VACUUM (VERBOSE, ANALYZE) onek;`\n\n## See Also\n\n- vacuumdb(1)\n\n## Section Outline\n\n- **NAME** (2 lines)\n- **SYNOPSIS** (20 lines)\n- **DESCRIPTION** (28 lines)\n- **PARAMETERS** (111 lines)\n- **OUTPUTS** (3 lines)\n- **NOTES** (38 lines)\n- **EXAMPLES** (5 lines)\n- **COMPATIBILITY** (2 lines)\n- **SEE ALSO** (5 lines)\n\n## Full Content\n\n### NAME\n\nVACUUM - garbage-collect and optionally analyze a database\n\n### SYNOPSIS\n\nVACUUM [ ( option [, ...] ) ] [ tableandcolumns [, ...] ]\nVACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ tableandcolumns [, ...] ]\n\nwhere option can be one of:\n\nFULL [ boolean ]\nFREEZE [ boolean ]\nVERBOSE [ boolean ]\nANALYZE [ boolean ]\nDISABLEPAGESKIPPING [ boolean ]\nSKIPLOCKED [ boolean ]\nINDEXCLEANUP { AUTO | ON | OFF }\nPROCESSTOAST [ boolean ]\nTRUNCATE [ boolean ]\nPARALLEL integer\n\nand tableandcolumns is:\n\ntablename [ ( columnname [, ...] ) ]\n\n### DESCRIPTION\n\nVACUUM reclaims storage occupied by dead tuples. In normal PostgreSQL operation, tuples that\nare deleted or obsoleted by an update are not physically removed from their table; they\nremain present until a VACUUM is done. Therefore it's necessary to do VACUUM periodically,\nespecially on frequently-updated tables.\n\nWithout a tableandcolumns list, VACUUM processes every table and materialized view in the\ncurrent database that the current user has permission to vacuum. With a list, VACUUM\nprocesses only those table(s).\n\nVACUUM ANALYZE performs a VACUUM and then an ANALYZE for each selected table. This is a handy\ncombination form for routine maintenance scripts. See ANALYZE(7) for more details about its\nprocessing.\n\nPlain VACUUM (without FULL) simply reclaims space and makes it available for re-use. This\nform of the command can operate in parallel with normal reading and writing of the table, as\nan exclusive lock is not obtained. However, extra space is not returned to the operating\nsystem (in most cases); it's just kept available for re-use within the same table. It also\nallows us to leverage multiple CPUs in order to process indexes. This feature is known as\nparallel vacuum. To disable this feature, one can use PARALLEL option and specify parallel\nworkers as zero.  VACUUM FULL rewrites the entire contents of the table into a new disk file\nwith no extra space, allowing unused space to be returned to the operating system. This form\nis much slower and requires an ACCESS EXCLUSIVE lock on each table while it is being\nprocessed.\n\nWhen the option list is surrounded by parentheses, the options can be written in any order.\nWithout parentheses, options must be specified in exactly the order shown above. The\nparenthesized syntax was added in PostgreSQL 9.0; the unparenthesized syntax is deprecated.\n\n### PARAMETERS\n\nFULL\nSelects “full” vacuum, which can reclaim more space, but takes much longer and\nexclusively locks the table. This method also requires extra disk space, since it writes\na new copy of the table and doesn't release the old copy until the operation is complete.\nUsually this should only be used when a significant amount of space needs to be reclaimed\nfrom within the table.\n\nFREEZE\nSelects aggressive “freezing” of tuples. Specifying FREEZE is equivalent to performing\nVACUUM with the vacuumfreezeminage and vacuumfreezetableage parameters set to zero.\nAggressive freezing is always performed when the table is rewritten, so this option is\nredundant when FULL is specified.\n\nVERBOSE\nPrints a detailed vacuum activity report for each table.\n\nANALYZE\nUpdates statistics used by the planner to determine the most efficient way to execute a\nquery.\n\nDISABLEPAGESKIPPING\nNormally, VACUUM will skip pages based on the visibility map. Pages where all tuples are\nknown to be frozen can always be skipped, and those where all tuples are known to be\nvisible to all transactions may be skipped except when performing an aggressive vacuum.\nFurthermore, except when performing an aggressive vacuum, some pages may be skipped in\norder to avoid waiting for other sessions to finish using them. This option disables all\npage-skipping behavior, and is intended to be used only when the contents of the\nvisibility map are suspect, which should happen only if there is a hardware or software\nissue causing database corruption.\n\nSKIPLOCKED\nSpecifies that VACUUM should not wait for any conflicting locks to be released when\nbeginning work on a relation: if a relation cannot be locked immediately without waiting,\nthe relation is skipped. Note that even with this option, VACUUM may still block when\nopening the relation's indexes. Additionally, VACUUM ANALYZE may still block when\nacquiring sample rows from partitions, table inheritance children, and some types of\nforeign tables. Also, while VACUUM ordinarily processes all partitions of specified\npartitioned tables, this option will cause VACUUM to skip all partitions if there is a\nconflicting lock on the partitioned table.\n\nINDEXCLEANUP\nNormally, VACUUM will skip index vacuuming when there are very few dead tuples in the\ntable. The cost of processing all of the table's indexes is expected to greatly exceed\nthe benefit of removing dead index tuples when this happens. This option can be used to\nforce VACUUM to process indexes when there are more than zero dead tuples. The default is\nAUTO, which allows VACUUM to skip index vacuuming when appropriate. If INDEXCLEANUP is\nset to ON, VACUUM will conservatively remove all dead tuples from indexes. This may be\nuseful for backwards compatibility with earlier releases of PostgreSQL where this was the\nstandard behavior.\n\nINDEXCLEANUP can also be set to OFF to force VACUUM to always skip index vacuuming, even\nwhen there are many dead tuples in the table. This may be useful when it is necessary to\nmake VACUUM run as quickly as possible to avoid imminent transaction ID wraparound (see\nSection 25.1.5). However, the wraparound failsafe mechanism controlled by\nvacuumfailsafeage will generally trigger automatically to avoid transaction ID\nwraparound failure, and should be preferred. If index cleanup is not performed regularly,\nperformance may suffer, because as the table is modified indexes will accumulate dead\ntuples and the table itself will accumulate dead line pointers that cannot be removed\nuntil index cleanup is completed.\n\nThis option has no effect for tables that have no index and is ignored if the FULL option\nis used. It also has no effect on the transaction ID wraparound failsafe mechanism. When\ntriggered it will skip index vacuuming, even when INDEXCLEANUP is set to ON.\n\nPROCESSTOAST\nSpecifies that VACUUM should attempt to process the corresponding TOAST table for each\nrelation, if one exists. This is usually the desired behavior and is the default. Setting\nthis option to false may be useful when it is only necessary to vacuum the main relation.\nThis option is required when the FULL option is used.\n\nTRUNCATE\nSpecifies that VACUUM should attempt to truncate off any empty pages at the end of the\ntable and allow the disk space for the truncated pages to be returned to the operating\nsystem. This is normally the desired behavior and is the default unless the\nvacuumtruncate option has been set to false for the table to be vacuumed. Setting this\noption to false may be useful to avoid ACCESS EXCLUSIVE lock on the table that the\ntruncation requires. This option is ignored if the FULL option is used.\n\nPARALLEL\nPerform index vacuum and index cleanup phases of VACUUM in parallel using integer\nbackground workers (for the details of each vacuum phase, please refer to Table 28.39).\nThe number of workers used to perform the operation is equal to the number of indexes on\nthe relation that support parallel vacuum which is limited by the number of workers\nspecified with PARALLEL option if any which is further limited by\nmaxparallelmaintenanceworkers. An index can participate in parallel vacuum if and only\nif the size of the index is more than minparallelindexscansize. Please note that it\nis not guaranteed that the number of parallel workers specified in integer will be used\nduring execution. It is possible for a vacuum to run with fewer workers than specified,\nor even with no workers at all. Only one worker can be used per index. So parallel\nworkers are launched only when there are at least 2 indexes in the table. Workers for\nvacuum are launched before the start of each phase and exit at the end of the phase.\nThese behaviors might change in a future release. This option can't be used with the FULL\noption.\n\nboolean\nSpecifies whether the selected option should be turned on or off. You can write TRUE, ON,\nor 1 to enable the option, and FALSE, OFF, or 0 to disable it. The boolean value can also\nbe omitted, in which case TRUE is assumed.\n\ninteger\nSpecifies a non-negative integer value passed to the selected option.\n\ntablename\nThe name (optionally schema-qualified) of a specific table or materialized view to\nvacuum. If the specified table is a partitioned table, all of its leaf partitions are\nvacuumed.\n\ncolumnname\nThe name of a specific column to analyze. Defaults to all columns. If a column list is\nspecified, ANALYZE must also be specified.\n\n### OUTPUTS\n\nWhen VERBOSE is specified, VACUUM emits progress messages to indicate which table is\ncurrently being processed. Various statistics about the tables are printed as well.\n\n### NOTES\n\nTo vacuum a table, one must ordinarily be the table's owner or a superuser. However, database\nowners are allowed to vacuum all tables in their databases, except shared catalogs. (The\nrestriction for shared catalogs means that a true database-wide VACUUM can only be performed\nby a superuser.)  VACUUM will skip over any tables that the calling user does not have\npermission to vacuum.\n\nVACUUM cannot be executed inside a transaction block.\n\nFor tables with GIN indexes, VACUUM (in any form) also completes any pending index\ninsertions, by moving pending index entries to the appropriate places in the main GIN index\nstructure. See Section 67.4.1 for details.\n\nWe recommend that active production databases be vacuumed frequently (at least nightly), in\norder to remove dead rows. After adding or deleting a large number of rows, it might be a\ngood idea to issue a VACUUM ANALYZE command for the affected table. This will update the\nsystem catalogs with the results of all recent changes, and allow the PostgreSQL query\nplanner to make better choices in planning queries.\n\nThe FULL option is not recommended for routine use, but might be useful in special cases. An\nexample is when you have deleted or updated most of the rows in a table and would like the\ntable to physically shrink to occupy less disk space and allow faster table scans.  VACUUM\nFULL will usually shrink the table more than a plain VACUUM would.\n\nThe PARALLEL option is used only for vacuum purposes. If this option is specified with the\nANALYZE option, it does not affect ANALYZE.\n\nVACUUM causes a substantial increase in I/O traffic, which might cause poor performance for\nother active sessions. Therefore, it is sometimes advisable to use the cost-based vacuum\ndelay feature. For parallel vacuum, each worker sleeps in proportion to the work done by that\nworker. See Section 20.4.4 for details.\n\nPostgreSQL includes an “autovacuum” facility which can automate routine vacuum maintenance.\nFor more information about automatic and manual vacuuming, see Section 25.1.\n\nEach backend running VACUUM without the FULL option will report its progress in the\npgstatprogressvacuum view. Backends running VACUUM FULL will instead report their progress\nin the pgstatprogresscluster view. See Section 28.4.3 and Section 28.4.4 for details.\n\n### EXAMPLES\n\nTo clean a single table onek, analyze it for the optimizer and print a detailed vacuum\nactivity report:\n\nVACUUM (VERBOSE, ANALYZE) onek;\n\n### COMPATIBILITY\n\nThere is no VACUUM statement in the SQL standard.\n\n### SEE ALSO\n\nvacuumdb(1), Section 20.4.4, Section 25.1.6, Section 28.4.3, Section 28.4.4\n\n\n\nPostgreSQL 14.23                                2026                                       VACUUM(7)\n\n"
        }
    ],
    "structuredContent": {
        "command": "VACUUM",
        "section": "",
        "mode": "man",
        "summary": "VACUUM - garbage-collect and optionally analyze a database",
        "synopsis": "VACUUM [ ( option [, ...] ) ] [ tableandcolumns [, ...] ]\nVACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ tableandcolumns [, ...] ]\nwhere option can be one of:\nFULL [ boolean ]\nFREEZE [ boolean ]\nVERBOSE [ boolean ]\nANALYZE [ boolean ]\nDISABLEPAGESKIPPING [ boolean ]\nSKIPLOCKED [ boolean ]\nINDEXCLEANUP { AUTO | ON | OFF }\nPROCESSTOAST [ boolean ]\nTRUNCATE [ boolean ]\nPARALLEL integer\nand tableandcolumns is:\ntablename [ ( columnname [, ...] ) ]",
        "tldr_summary": null,
        "tldr_examples": [],
        "tldr_source": null,
        "flags": [],
        "examples": [
            "To clean a single table onek, analyze it for the optimizer and print a detailed vacuum",
            "activity report:",
            "VACUUM (VERBOSE, ANALYZE) onek;"
        ],
        "see_also": [
            {
                "name": "vacuumdb",
                "section": "1",
                "url": "https://www.chedong.com/phpMan.php/man/vacuumdb/1/json"
            }
        ],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "SYNOPSIS",
                "lines": 20,
                "subsections": []
            },
            {
                "name": "DESCRIPTION",
                "lines": 28,
                "subsections": []
            },
            {
                "name": "PARAMETERS",
                "lines": 111,
                "subsections": []
            },
            {
                "name": "OUTPUTS",
                "lines": 3,
                "subsections": []
            },
            {
                "name": "NOTES",
                "lines": 38,
                "subsections": []
            },
            {
                "name": "EXAMPLES",
                "lines": 5,
                "subsections": []
            },
            {
                "name": "COMPATIBILITY",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "SEE ALSO",
                "lines": 5,
                "subsections": []
            }
        ],
        "sections": {
            "NAME": {
                "content": "VACUUM - garbage-collect and optionally analyze a database\n",
                "subsections": []
            },
            "SYNOPSIS": {
                "content": "VACUUM [ ( option [, ...] ) ] [ tableandcolumns [, ...] ]\nVACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ tableandcolumns [, ...] ]\n\nwhere option can be one of:\n\nFULL [ boolean ]\nFREEZE [ boolean ]\nVERBOSE [ boolean ]\nANALYZE [ boolean ]\nDISABLEPAGESKIPPING [ boolean ]\nSKIPLOCKED [ boolean ]\nINDEXCLEANUP { AUTO | ON | OFF }\nPROCESSTOAST [ boolean ]\nTRUNCATE [ boolean ]\nPARALLEL integer\n\nand tableandcolumns is:\n\ntablename [ ( columnname [, ...] ) ]\n",
                "subsections": []
            },
            "DESCRIPTION": {
                "content": "VACUUM reclaims storage occupied by dead tuples. In normal PostgreSQL operation, tuples that\nare deleted or obsoleted by an update are not physically removed from their table; they\nremain present until a VACUUM is done. Therefore it's necessary to do VACUUM periodically,\nespecially on frequently-updated tables.\n\nWithout a tableandcolumns list, VACUUM processes every table and materialized view in the\ncurrent database that the current user has permission to vacuum. With a list, VACUUM\nprocesses only those table(s).\n\nVACUUM ANALYZE performs a VACUUM and then an ANALYZE for each selected table. This is a handy\ncombination form for routine maintenance scripts. See ANALYZE(7) for more details about its\nprocessing.\n\nPlain VACUUM (without FULL) simply reclaims space and makes it available for re-use. This\nform of the command can operate in parallel with normal reading and writing of the table, as\nan exclusive lock is not obtained. However, extra space is not returned to the operating\nsystem (in most cases); it's just kept available for re-use within the same table. It also\nallows us to leverage multiple CPUs in order to process indexes. This feature is known as\nparallel vacuum. To disable this feature, one can use PARALLEL option and specify parallel\nworkers as zero.  VACUUM FULL rewrites the entire contents of the table into a new disk file\nwith no extra space, allowing unused space to be returned to the operating system. This form\nis much slower and requires an ACCESS EXCLUSIVE lock on each table while it is being\nprocessed.\n\nWhen the option list is surrounded by parentheses, the options can be written in any order.\nWithout parentheses, options must be specified in exactly the order shown above. The\nparenthesized syntax was added in PostgreSQL 9.0; the unparenthesized syntax is deprecated.\n",
                "subsections": []
            },
            "PARAMETERS": {
                "content": "FULL\nSelects “full” vacuum, which can reclaim more space, but takes much longer and\nexclusively locks the table. This method also requires extra disk space, since it writes\na new copy of the table and doesn't release the old copy until the operation is complete.\nUsually this should only be used when a significant amount of space needs to be reclaimed\nfrom within the table.\n\nFREEZE\nSelects aggressive “freezing” of tuples. Specifying FREEZE is equivalent to performing\nVACUUM with the vacuumfreezeminage and vacuumfreezetableage parameters set to zero.\nAggressive freezing is always performed when the table is rewritten, so this option is\nredundant when FULL is specified.\n\nVERBOSE\nPrints a detailed vacuum activity report for each table.\n\nANALYZE\nUpdates statistics used by the planner to determine the most efficient way to execute a\nquery.\n\nDISABLEPAGESKIPPING\nNormally, VACUUM will skip pages based on the visibility map. Pages where all tuples are\nknown to be frozen can always be skipped, and those where all tuples are known to be\nvisible to all transactions may be skipped except when performing an aggressive vacuum.\nFurthermore, except when performing an aggressive vacuum, some pages may be skipped in\norder to avoid waiting for other sessions to finish using them. This option disables all\npage-skipping behavior, and is intended to be used only when the contents of the\nvisibility map are suspect, which should happen only if there is a hardware or software\nissue causing database corruption.\n\nSKIPLOCKED\nSpecifies that VACUUM should not wait for any conflicting locks to be released when\nbeginning work on a relation: if a relation cannot be locked immediately without waiting,\nthe relation is skipped. Note that even with this option, VACUUM may still block when\nopening the relation's indexes. Additionally, VACUUM ANALYZE may still block when\nacquiring sample rows from partitions, table inheritance children, and some types of\nforeign tables. Also, while VACUUM ordinarily processes all partitions of specified\npartitioned tables, this option will cause VACUUM to skip all partitions if there is a\nconflicting lock on the partitioned table.\n\nINDEXCLEANUP\nNormally, VACUUM will skip index vacuuming when there are very few dead tuples in the\ntable. The cost of processing all of the table's indexes is expected to greatly exceed\nthe benefit of removing dead index tuples when this happens. This option can be used to\nforce VACUUM to process indexes when there are more than zero dead tuples. The default is\nAUTO, which allows VACUUM to skip index vacuuming when appropriate. If INDEXCLEANUP is\nset to ON, VACUUM will conservatively remove all dead tuples from indexes. This may be\nuseful for backwards compatibility with earlier releases of PostgreSQL where this was the\nstandard behavior.\n\nINDEXCLEANUP can also be set to OFF to force VACUUM to always skip index vacuuming, even\nwhen there are many dead tuples in the table. This may be useful when it is necessary to\nmake VACUUM run as quickly as possible to avoid imminent transaction ID wraparound (see\nSection 25.1.5). However, the wraparound failsafe mechanism controlled by\nvacuumfailsafeage will generally trigger automatically to avoid transaction ID\nwraparound failure, and should be preferred. If index cleanup is not performed regularly,\nperformance may suffer, because as the table is modified indexes will accumulate dead\ntuples and the table itself will accumulate dead line pointers that cannot be removed\nuntil index cleanup is completed.\n\nThis option has no effect for tables that have no index and is ignored if the FULL option\nis used. It also has no effect on the transaction ID wraparound failsafe mechanism. When\ntriggered it will skip index vacuuming, even when INDEXCLEANUP is set to ON.\n\nPROCESSTOAST\nSpecifies that VACUUM should attempt to process the corresponding TOAST table for each\nrelation, if one exists. This is usually the desired behavior and is the default. Setting\nthis option to false may be useful when it is only necessary to vacuum the main relation.\nThis option is required when the FULL option is used.\n\nTRUNCATE\nSpecifies that VACUUM should attempt to truncate off any empty pages at the end of the\ntable and allow the disk space for the truncated pages to be returned to the operating\nsystem. This is normally the desired behavior and is the default unless the\nvacuumtruncate option has been set to false for the table to be vacuumed. Setting this\noption to false may be useful to avoid ACCESS EXCLUSIVE lock on the table that the\ntruncation requires. This option is ignored if the FULL option is used.\n\nPARALLEL\nPerform index vacuum and index cleanup phases of VACUUM in parallel using integer\nbackground workers (for the details of each vacuum phase, please refer to Table 28.39).\nThe number of workers used to perform the operation is equal to the number of indexes on\nthe relation that support parallel vacuum which is limited by the number of workers\nspecified with PARALLEL option if any which is further limited by\nmaxparallelmaintenanceworkers. An index can participate in parallel vacuum if and only\nif the size of the index is more than minparallelindexscansize. Please note that it\nis not guaranteed that the number of parallel workers specified in integer will be used\nduring execution. It is possible for a vacuum to run with fewer workers than specified,\nor even with no workers at all. Only one worker can be used per index. So parallel\nworkers are launched only when there are at least 2 indexes in the table. Workers for\nvacuum are launched before the start of each phase and exit at the end of the phase.\nThese behaviors might change in a future release. This option can't be used with the FULL\noption.\n\nboolean\nSpecifies whether the selected option should be turned on or off. You can write TRUE, ON,\nor 1 to enable the option, and FALSE, OFF, or 0 to disable it. The boolean value can also\nbe omitted, in which case TRUE is assumed.\n\ninteger\nSpecifies a non-negative integer value passed to the selected option.\n\ntablename\nThe name (optionally schema-qualified) of a specific table or materialized view to\nvacuum. If the specified table is a partitioned table, all of its leaf partitions are\nvacuumed.\n\ncolumnname\nThe name of a specific column to analyze. Defaults to all columns. If a column list is\nspecified, ANALYZE must also be specified.\n",
                "subsections": []
            },
            "OUTPUTS": {
                "content": "When VERBOSE is specified, VACUUM emits progress messages to indicate which table is\ncurrently being processed. Various statistics about the tables are printed as well.\n",
                "subsections": []
            },
            "NOTES": {
                "content": "To vacuum a table, one must ordinarily be the table's owner or a superuser. However, database\nowners are allowed to vacuum all tables in their databases, except shared catalogs. (The\nrestriction for shared catalogs means that a true database-wide VACUUM can only be performed\nby a superuser.)  VACUUM will skip over any tables that the calling user does not have\npermission to vacuum.\n\nVACUUM cannot be executed inside a transaction block.\n\nFor tables with GIN indexes, VACUUM (in any form) also completes any pending index\ninsertions, by moving pending index entries to the appropriate places in the main GIN index\nstructure. See Section 67.4.1 for details.\n\nWe recommend that active production databases be vacuumed frequently (at least nightly), in\norder to remove dead rows. After adding or deleting a large number of rows, it might be a\ngood idea to issue a VACUUM ANALYZE command for the affected table. This will update the\nsystem catalogs with the results of all recent changes, and allow the PostgreSQL query\nplanner to make better choices in planning queries.\n\nThe FULL option is not recommended for routine use, but might be useful in special cases. An\nexample is when you have deleted or updated most of the rows in a table and would like the\ntable to physically shrink to occupy less disk space and allow faster table scans.  VACUUM\nFULL will usually shrink the table more than a plain VACUUM would.\n\nThe PARALLEL option is used only for vacuum purposes. If this option is specified with the\nANALYZE option, it does not affect ANALYZE.\n\nVACUUM causes a substantial increase in I/O traffic, which might cause poor performance for\nother active sessions. Therefore, it is sometimes advisable to use the cost-based vacuum\ndelay feature. For parallel vacuum, each worker sleeps in proportion to the work done by that\nworker. See Section 20.4.4 for details.\n\nPostgreSQL includes an “autovacuum” facility which can automate routine vacuum maintenance.\nFor more information about automatic and manual vacuuming, see Section 25.1.\n\nEach backend running VACUUM without the FULL option will report its progress in the\npgstatprogressvacuum view. Backends running VACUUM FULL will instead report their progress\nin the pgstatprogresscluster view. See Section 28.4.3 and Section 28.4.4 for details.\n",
                "subsections": []
            },
            "EXAMPLES": {
                "content": "To clean a single table onek, analyze it for the optimizer and print a detailed vacuum\nactivity report:\n\nVACUUM (VERBOSE, ANALYZE) onek;\n",
                "subsections": []
            },
            "COMPATIBILITY": {
                "content": "There is no VACUUM statement in the SQL standard.\n",
                "subsections": []
            },
            "SEE ALSO": {
                "content": "vacuumdb(1), Section 20.4.4, Section 25.1.6, Section 28.4.3, Section 28.4.4\n\n\n\nPostgreSQL 14.23                                2026                                       VACUUM(7)",
                "subsections": []
            }
        }
    }
}