<listitem>

<simpara>To update the visibility map, which speeds up index-only

scans.</simpara>

</listitem>

<sect2 id="vacuum-for-visibility-map">

<title>Updating The Visibility Map</title>

<para>

Vacuum maintains a <link linkend="storage-vm">visibility map</> for each

table to keep track of which pages contain only tuples that are known to be

visible to all active transactions (and all future transactions, until the

page is again modified). 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, it allows <productname>PostgreSQL</productname> to answer some

queries using only the index, without reference to the underlying table.

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 <firstterm>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.

The visibility map is vastly smaller than the heap, so it can easily be

cached even when the heap is very large.

</para>

</sect2>

This means that the page does not contain any tuples that need to be vacuumed.

This information can also be used by <firstterm>index-only scans</> to answer

queries using only the index tuple.

</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.