|
3 | 3 | * vacuumlazy.c |
4 | 4 | * Concurrent ("lazy") vacuuming. |
5 | 5 | * |
| 6 | + * Heap relations are vacuumed in three main phases. In phase I, vacuum scans |
| 7 | + * relation pages, pruning and freezing tuples and saving dead tuples' TIDs in |
| 8 | + * a TID store. If that TID store fills up or vacuum finishes scanning the |
| 9 | + * relation, it progresses to phase II: index vacuuming. Index vacuuming |
| 10 | + * deletes the dead index entries referenced in the TID store. In phase III, |
| 11 | + * vacuum scans the blocks of the relation referred to by the TIDs in the TID |
| 12 | + * store and reaps the corresponding dead items, freeing that space for future |
| 13 | + * tuples. |
| 14 | + * |
| 15 | + * If there are no indexes or index scanning is disabled, phase II may be |
| 16 | + * skipped. If phase I identified very few dead index entries or if vacuum's |
| 17 | + * failsafe mechanism has triggered (to avoid transaction ID wraparound), |
| 18 | + * vacuum may skip phases II and III. |
| 19 | + * |
| 20 | + * If the TID store fills up in phase I, vacuum suspends phase I, proceeds to |
| 21 | + * phases II and II, cleaning up the dead tuples referenced in the current TID |
| 22 | + * store. This empties the TID store resumes phase I. |
| 23 | + * |
| 24 | + * In a way, the phases are more like states in a state machine, but they have |
| 25 | + * been referred to colloquially as phases for so long that they are referred |
| 26 | + * to as such here. |
| 27 | + * |
| 28 | + * Manually invoked VACUUMs may scan indexes during phase II in parallel. For |
| 29 | + * more information on this, see the comment at the top of vacuumparallel.c. |
| 30 | + * |
| 31 | + * In between phases, vacuum updates the freespace map (every |
| 32 | + * VACUUM_FSM_EVERY_PAGES). |
| 33 | + * |
| 34 | + * After completing all three phases, vacuum may truncate the relation if it |
| 35 | + * has emptied pages at the end. Finally, vacuum updates relation statistics |
| 36 | + * in pg_class and the cumulative statistics subsystem. |
| 37 | + * |
| 38 | + * Relation Scanning: |
| 39 | + * |
| 40 | + * Vacuum scans the heap relation, starting at the beginning and progressing |
| 41 | + * to the end, skipping pages as permitted by their visibility status, vacuum |
| 42 | + * options, and various other requirements. |
| 43 | + * |
| 44 | + * When page skipping is not disabled, a non-aggressive vacuum may scan pages |
| 45 | + * that are marked all-visible (and even all-frozen) in the visibility map if |
| 46 | + * the range of skippable pages is below SKIP_PAGES_THRESHOLD. |
| 47 | + * |
| 48 | + * Once vacuum has decided to scan a given block, it must read the block and |
| 49 | + * obtain a cleanup lock to prune tuples on the page. A non-aggressive vacuum |
| 50 | + * may choose to skip pruning and freezing if it cannot acquire a cleanup lock |
| 51 | + * on the buffer right away. In this case, it may miss cleaning up dead tuples |
| 52 | + * and their associated index entries (though it is free to reap any existing |
| 53 | + * dead items on the page). |
| 54 | + * |
| 55 | + * After pruning and freezing, pages that are newly all-visible and all-frozen |
| 56 | + * are marked as such in the visibility map. |
| 57 | + * |
| 58 | + * Dead TID Storage: |
| 59 | + * |
6 | 60 | * The major space usage for vacuuming is storage for the dead tuple IDs that |
7 | 61 | * are to be removed from indexes. We want to ensure we can vacuum even the |
8 | 62 | * very largest relations with finite memory space usage. To do that, we set |
|