|
478 | 478 | </note>
|
479 | 479 |
|
480 | 480 | <para>
|
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. |
| 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. |
488 | 505 | </para>
|
489 | 506 |
|
490 | 507 | <para>
|
|
506 | 523 | always use its aggressive strategy.
|
507 | 524 | </para>
|
508 | 525 |
|
| 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 | + |
509 | 535 | <para>
|
510 | 536 | The maximum time that a table can go unvacuumed is two billion
|
511 | 537 | transactions minus the <varname>vacuum_freeze_min_age</varname> value at
|
512 | 538 | the time of the last aggressive vacuum. If it were to go
|
513 |
| - unvacuumed for longer than |
514 |
| - that, data loss could result. To ensure that this does not happen, |
| 539 | + unvacuumed for longer than that, the system could temporarily refuse to |
| 540 | + allocate new transaction IDs. To ensure that this never happens, |
515 | 541 | autovacuum is invoked on any table that might contain unfrozen rows with
|
516 | 542 | XIDs older than the age specified by the configuration parameter <xref
|
517 | 543 | linkend="guc-autovacuum-freeze-max-age"/>. (This will happen even if
|
|
551 | 577 | </para>
|
552 | 578 |
|
553 | 579 | <para>
|
554 |
| - The sole disadvantage of increasing <varname>autovacuum_freeze_max_age</varname> |
| 580 | + One disadvantage of increasing <varname>autovacuum_freeze_max_age</varname> |
555 | 581 | (and <varname>vacuum_freeze_table_age</varname> along with it) is that
|
556 | 582 | the <filename>pg_xact</filename> and <filename>pg_commit_ts</filename>
|
557 | 583 | subdirectories of the database cluster will take more space, because it
|
@@ -837,8 +863,8 @@ vacuum insert threshold = vacuum base insert threshold + vacuum insert scale fac
|
837 | 863 | For tables which receive <command>INSERT</command> operations but no or
|
838 | 864 | almost no <command>UPDATE</command>/<command>DELETE</command> operations,
|
839 | 865 | it may be beneficial to lower the table's
|
840 |
| - <xref linkend="reloption-autovacuum-freeze-min-age"/> as this may allow |
841 |
| - tuples to be frozen by earlier vacuums. The number of obsolete tuples and |
| 866 | + <xref linkend="reloption-autovacuum-freeze-strategy-threshold"/> |
| 867 | + to allow freezing to take place proactively. The number of obsolete tuples and |
842 | 868 | the number of inserted tuples are obtained from the cumulative statistics system;
|
843 | 869 | it is a semi-accurate count updated by each <command>UPDATE</command>,
|
844 | 870 | <command>DELETE</command> and <command>INSERT</command> operation. (It is
|
|
0 commit comments