diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
new file mode 100644
index 03cc6c9..e042293
*** a/doc/src/sgml/maintenance.sgml
--- b/doc/src/sgml/maintenance.sgml
***************
*** 102,107 ****
--- 102,112 ----
       </listitem>
  
       <listitem>
+       <simpara>To update the visibility map, which speeds up index-only
+       scans.</simpara>
+      </listitem>
+ 
+      <listitem>
        <simpara>To protect against loss of very old data due to
        <firstterm>transaction ID wraparound</>.</simpara>
       </listitem>
***************
*** 329,334 ****
--- 334,361 ----
     </tip>
    </sect2>
  
+   <sect2 id="vacuum-for-visibility-map">
+    <title>Updating Visibility Map</title>
+ 
+    <para>
+     Vacuum maintains the table <xref linkend="storage-vm">, which keeps track
+     of pages that only contain tuples that are visible to all transactions.
+     This has two purposes.  First, vacuum itself can skip such pages on the
+     next run, since there is nothing to clean up.
+    </para>
+ 
+    <para>
+     Second, index-only scans also take advantage of the visibility map. Since
+     <productname>PostgreSQL</productname> indexes don't contain tuple
+     visibility information, a normal index scan fetches the heap tuple for each
+     matching index entry, to check whether it should be seen by the current
+     transaction.  An index-only scan, on the other hand, checks the
+     visibility map first.  If it's known that all tuples on the page are
+     visible, the heap fetch can be skipped.  This is most noticeable on
+     large data sets where the visibility map can prevent disk accesses.
+    </para>
+   </sect2>
+ 
    <sect2 id="vacuum-for-wraparound">
     <title>Preventing Transaction ID Wraparound Failures</title>
  
diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml
new file mode 100644
index cb2f60e..a1c300d
*** a/doc/src/sgml/storage.sgml
--- b/doc/src/sgml/storage.sgml
*************** Note that indexes do not have VMs.
*** 494,504 ****
  <para>
  The visibility map simply stores one bit per heap page. A set bit means
  that all tuples on the page are known to be visible to all transactions.
! This means that the page does not contain any tuples that need to be vacuumed;
! in future it might also be used to avoid visiting the page for visibility
! checks. The map is conservative in the sense that we
! make sure that whenever a bit is set, we know the condition is true, but if
! a bit is not set, it might or might not be true.
  </para>
  
  </sect1>
--- 494,509 ----
  <para>
  The visibility map simply stores one bit per heap page. A set bit means
  that all tuples on the page are known to be visible to all transactions.
! This information is used by vacuum to skip pages that do not contain any
! tuples that need to be vacuumed and by <fistterm>index-only scans</> to skip
! row visibility checks to the table heap.
! </para>
! 
! <para>
! The map is conservative in the sense that we make sure that whenever a bit is
! set, we know the condition is true, but if a bit is not set, it might or
! might not be true. Visibility map bits are only set by vacuum, but are
! cleared by any data-modifying operations on a page.
  </para>
  
  </sect1>