|
478 | 478 | </note>
|
479 | 479 |
|
480 | 480 | <para>
|
481 |
| - <xref linkend="guc-vacuum-freeze-strategy-threshold"/> controls |
482 |
| - <command>VACUUM</command>'s freezing strategy. The |
483 |
| - <firstterm>eager freezing strategy</firstterm> makes |
484 |
| - <command>VACUUM</command> freeze all rows on a page whenever each |
485 |
| - and every row on the page is considered visible to all current |
486 |
| - transactions (immediately after dead row versions are removed). |
487 |
| - Freezing pages early and in batch often spreads out the overhead |
488 |
| - of freezing over time. <command>VACUUM</command> consistently |
489 |
| - avoids allowing unfrozen all-visible pages to build up, improving |
490 |
| - system level performance stability. The <firstterm>lazy freezing |
491 |
| - strategy</firstterm> makes <command>VACUUM</command> determine |
492 |
| - whether pages should be frozen on the basis of the age of the |
493 |
| - oldest XID on the page. Freezing pages lazily sometimes avoids |
494 |
| - the overhead of freezing that turns out to have been unnecessary |
495 |
| - because the rows were modified soon after freezing took place. |
496 |
| - </para> |
497 |
| - |
498 |
| - <para> |
499 |
| - <xref linkend="guc-vacuum-freeze-min-age"/> controls how old an |
500 |
| - XID value has to be before pages with rows bearing that XID are |
501 |
| - frozen. This setting is an additional trigger criteria for |
502 |
| - freezing a page's tuples. It is used by both freezing strategies, |
503 |
| - though it typically has little impact when <command>VACUUM</command> |
504 |
| - uses the eager freezing strategy. |
| 481 | + <xref linkend="guc-vacuum-freeze-min-age"/> |
| 482 | + controls how old an XID value has to be before rows bearing that XID will be |
| 483 | + frozen. Increasing this setting may avoid unnecessary work if the |
| 484 | + rows that would otherwise be frozen will soon be modified again, |
| 485 | + but decreasing this setting increases |
| 486 | + the number of transactions that can elapse before the table must be |
| 487 | + vacuumed again. |
505 | 488 | </para>
|
506 | 489 |
|
507 | 490 | <para>
|
|
523 | 506 | always use its aggressive strategy.
|
524 | 507 | </para>
|
525 | 508 |
|
526 |
| - <para> |
527 |
| - Controlling the overhead of freezing existing all-visible pages |
528 |
| - during aggressive vacuuming is the goal of the eager freezing |
529 |
| - strategy. Increasing <varname>vacuum_freeze_strategy_threshold</varname> |
530 |
| - may avoid unnecessary work, but it increases the risk of an |
531 |
| - eventual aggressive vacuum that performs an excessive amount of |
532 |
| - <quote>catch up</quote> freezing all at once. |
533 |
| - </para> |
534 |
| - |
535 | 509 | <para>
|
536 | 510 | The maximum time that a table can go unvacuumed is two billion
|
537 | 511 | transactions minus the <varname>vacuum_freeze_min_age</varname> value at
|
538 | 512 | the time of the last aggressive vacuum. If it were to go
|
539 |
| - unvacuumed for longer than that, the system could temporarily refuse to |
540 |
| - allocate new transaction IDs. To ensure that this never happens, |
| 513 | + unvacuumed for longer than |
| 514 | + that, data loss could result. To ensure that this does not happen, |
541 | 515 | autovacuum is invoked on any table that might contain unfrozen rows with
|
542 | 516 | XIDs older than the age specified by the configuration parameter <xref
|
543 | 517 | linkend="guc-autovacuum-freeze-max-age"/>. (This will happen even if
|
|
577 | 551 | </para>
|
578 | 552 |
|
579 | 553 | <para>
|
580 |
| - One disadvantage of increasing <varname>autovacuum_freeze_max_age</varname> |
| 554 | + The sole disadvantage of increasing <varname>autovacuum_freeze_max_age</varname> |
581 | 555 | (and <varname>vacuum_freeze_table_age</varname> along with it) is that
|
582 | 556 | the <filename>pg_xact</filename> and <filename>pg_commit_ts</filename>
|
583 | 557 | subdirectories of the database cluster will take more space, because it
|
@@ -864,8 +838,8 @@ vacuum insert threshold = vacuum base insert threshold + vacuum insert scale fac
|
864 | 838 | For tables which receive <command>INSERT</command> operations but no or
|
865 | 839 | almost no <command>UPDATE</command>/<command>DELETE</command> operations,
|
866 | 840 | it may be beneficial to lower the table's
|
867 |
| - <xref linkend="reloption-autovacuum-freeze-strategy-threshold"/> |
868 |
| - to allow freezing to take place proactively. The number of obsolete tuples and |
| 841 | + <xref linkend="reloption-autovacuum-freeze-min-age"/> as this may allow |
| 842 | + tuples to be frozen by earlier vacuums. The number of obsolete tuples and |
869 | 843 | the number of inserted tuples are obtained from the cumulative statistics system;
|
870 | 844 | it is a semi-accurate count updated by each <command>UPDATE</command>,
|
871 | 845 | <command>DELETE</command> and <command>INSERT</command> operation. (It is
|
|
0 commit comments