@@ -664,7 +664,7 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
664
664
certain implementation-level heuristics will fail to identify and
665
665
delete even one garbage index tuple (in which case a page split or
666
666
deduplication pass resolves the issue of an incoming new tuple not
667
- fitting on a leaf page). The worst case number of versions that
667
+ fitting on a leaf page). The worst- case number of versions that
668
668
any index scan must traverse (for any single logical row) is an
669
669
important contributor to overall system responsiveness and
670
670
throughput. A bottom-up index deletion pass targets suspected
@@ -706,7 +706,7 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
706
706
This is expected with any B-Tree index that is subject to
707
707
significant version churn from <command>UPDATE</command>s that
708
708
rarely or never logically modify the columns that the index covers.
709
- The average and worst case number of versions per logical row can
709
+ The average and worst- case number of versions per logical row can
710
710
be kept low purely through targeted incremental deletion passes.
711
711
It's quite possible that the on-disk size of certain indexes will
712
712
never increase by even one single page/block despite
@@ -811,7 +811,7 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
811
811
constraints) to use deduplication. This allows leaf pages to
812
812
temporarily <quote>absorb</quote> extra version churn duplicates.
813
813
Deduplication in unique indexes augments bottom-up index deletion,
814
- especially in cases where a long-running transactions holds a
814
+ especially in cases where a long-running transaction holds a
815
815
snapshot that blocks garbage collection. The goal is to buy time
816
816
for the bottom-up index deletion strategy to become effective
817
817
again. Delaying page splits until a single long-running
0 commit comments