aboutsummaryrefslogtreecommitdiff
path: root/doc/src/sgml/pgvisibility.sgml
blob: 4cdca7dada9a0373e23baefe99e41db8244e0ecf (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
<!-- doc/src/sgml/pgvisibility.sgml -->

<sect1 id="pgvisibility" xreflabel="pg_visibility">
 <title>pg_visibility</title>

 <indexterm zone="pgvisibility">
  <primary>pg_visibility</primary>
 </indexterm>

 <para>
  The <filename>pg_visibility</> module provides a means for examining the
  visibility map (VM) and page-level visibility information.
 </para>

 <para>
  These routines return information about three different bits.  The
  all-visible bit in the visibility map indicates that every tuple on
  a given page of a relation is visible to every current transaction.  The
  all-frozen bit in the visibility map indicates that every tuple on the
  page is frozen; that is, no future vacuum will need to modify the page
  until such time as a tuple is inserted, updated, deleted, or locked on
  that page.  The page-level <literal>PD_ALL_VISIBLE</literal> bit has the
  same meaning as the all-visible bit in the visibility map, but is stored
  within the data page itself rather than a separate data structure.  These
  will normally agree, but the page-level bit can sometimes be set while the
  visibility map bit is clear after a crash recovery; or they can disagree
  because of a change which occurs after <literal>pg_visibility</> examines
  the visibility map and before it examines the data page.
 </para>

 <para>
  Functions which display information about <literal>PD_ALL_VISIBLE</>
  are much more costly than those which only consult the visibility map,
  because they must read the relation's data blocks rather than only the
  (much smaller) visibility map.  Functions that check the relation's
  data blocks are similarly expensive.
 </para>

 <sect2>
  <title>Functions</title>

  <variablelist>
   <varlistentry>
    <term><function>pg_visibility_map(regclass, blkno bigint, all_visible OUT boolean, all_frozen OUT boolean) returns record</function></term>
    <listitem>
     <para>
      Returns the all-visible and all-frozen bits in the visibility map for
      the given block of the given relation.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><function>pg_visibility(regclass, blkno bigint, all_visible OUT boolean, all_frozen OUT boolean, pd_all_visible OUT boolean) returns record</function></term>
    <listitem>
     <para>
      Returns the all-visible and all-frozen bits in the visibility map for
      the given block of the given relation, plus the
      <literal>PD_ALL_VISIBILE</> bit for that block.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><function>pg_visibility_map(regclass, blkno OUT bigint, all_visible OUT boolean, all_frozen OUT boolean) returns record</function></term>
    <listitem>
     <para>
      Returns the all-visible and all-frozen bits in the visibility map for
      each block the given relation.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><function>pg_visibility(regclass, blkno OUT bigint, all_visible OUT boolean, all_frozen OUT boolean, pd_all_visible OUT boolean) returns record</function></term>

    <listitem>
     <para>
      Returns the all-visible and all-frozen bits in the visibility map for
      each block the given relation, plus the <literal>PD_ALL_VISIBLE</>
      bit for each block.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><function>pg_visibility_map_summary(regclass, all_visible OUT bigint, all_frozen OUT bigint) returns record</function></term>

    <listitem>
     <para>
      Returns the number of all-visible pages and the number of all-frozen
      pages in the relation according to the visibility map.
     </para>
    </listitem>
   </varlistentry>
  
   <varlistentry>
    <term><function>pg_check_frozen(regclass, t_ctid OUT tid) returns setof tid</function></term>

    <listitem>
     <para>
      Returns the TIDs of non-frozen tuples present in pages marked all-frozen
      in the visibility map.  If this function returns a non-empty set of
      TIDs, the database is corrupt.
     </para>
    </listitem>
   </varlistentry>
     
    <varlistentry>
    <term><function>pg_check_visible(regclass, t_ctid OUT tid) returns setof tid</function></term>

    <listitem>
     <para>
      Returns the TIDs of tuples which are not all-visible despite the fact
      that the pages which contain them are marked as all-visible in the
      visibility map.  If this function returns a non-empty set of TIDs, the
      database is corrupt.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>

  <para>
   By default, these functions are not publicly executable.
  </para>
 </sect2>

 <sect2>
  <title>Author</title>

  <para>
   Robert Haas <email>rhaas@postgresql.org</email>
  </para>
 </sect2>

</sect1>