70.4. Visibility Map

|  70.4. Visibility Map  |                  |                                     |                  |                          |
|:----------------------:|------------------|-------------------------------------|------------------|--------------------------|
|[Prev](storage-fsm.html)|[Up](storage.html)|Chapter 70. Database Physical Storage|[Home](index.html)| [Next](storage-init.html)|

---

## 70.4. Visibility Map

[]()[]()

Each heap relation has a Visibility Map
(VM) to keep track of which pages contain only tuples that are known to be
visible to all active transactions; it also keeps track of which pages contain
only frozen tuples. It's stored
alongside the main relation data in a separate relation fork, named after the
filenode number of the relation, plus a `_vm` suffix. For example,
if the filenode of a relation is 12345, the VM is stored in a file called`12345_vm`, in the same directory as the main relation file.
Note that indexes do not have VMs.

The visibility map stores two bits per heap page. The first bit, if set,
indicates that the page is all-visible, or in other words that the page does
not contain any tuples that need to be vacuumed.
This information can also be used
by [*index-only
scans*](indexes-index-only-scans.html) to answer queries using only the index tuple.
The second bit, if set, means that all tuples on the page have been frozen.
That means that even an anti-wraparound vacuum need not revisit the page.

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.

The [pg\_visibility](pgvisibility.html) module can be used to examine the
information stored in the visibility map.

---

|[Prev](storage-fsm.html)|[Up](storage.html)|   [Next](storage-init.html)  |
|:-----------------------|:----------------:|-----------------------------:|
|  70.3. Free Space Map  |[Home](index.html)| 70.5. The Initialization Fork|

 // \<![CDATA[ \<-- For SVG support if ('WebSocket' in window) { (function() { function refreshCSS() { var sheets = [].slice.call(document.getElementsByTagName("link")); var head = document.getElementsByTagName("head")[0]; for (var i = 0; i \< sheets.length; ++i) { var elem = sheets[i]; head.removeChild(elem); var rel = elem.rel; if (elem.href && typeof rel != "string" || rel.length == 0 || rel.toLowerCase() == "stylesheet") { var url = elem.href.replace(/(&|\\?)\_cacheOverride=\\d+/, ''); elem.href = url + (url.indexOf('?') \>= 0 ? '&' : '?') + '\_cacheOverride=' + (new Date().valueOf()); } head.appendChild(elem); } } var protocol = window.location.protocol === 'http:' ? 'ws://' : 'wss://'; var address = protocol + window.location.host + window.location.pathname + '/ws'; var socket = new WebSocket(address); socket.onmessage = function(msg) { if (msg.data == 'reload') window.location.reload(); else if (msg.data == 'refreshcss') refreshCSS(); }; console.log('Live reload enabled.'); })(); } // ]]\>