| blob | 4d42dd16e1038cb27445ca72d22f9170f8902d61 |
1 /*-------------------------------------------------------------------------
2 *
3 * tuptable.h
4 * tuple table support stuff
5 *
6 *
7 * Portions Copyright (c) 1996-2008, PostgreSQL Global Development Group
8 * Portions Copyright (c) 1994, Regents of the University of California
9 *
10 * $PostgreSQL$
11 *
12 *-------------------------------------------------------------------------
13 */
14 #ifndef TUPTABLE_H
15 #define TUPTABLE_H
21 /*----------
22 * The executor stores tuples in a "tuple table" which is composed of
23 * independent TupleTableSlots. There are several cases we need to handle:
24 * 1. physical tuple in a disk buffer page
25 * 2. physical tuple constructed in palloc'ed memory
26 * 3. "minimal" physical tuple constructed in palloc'ed memory
27 * 4. "virtual" tuple consisting of Datum/isnull arrays
28 *
29 * The first two cases are similar in that they both deal with "materialized"
30 * tuples, but resource management is different. For a tuple in a disk page
31 * we need to hold a pin on the buffer until the TupleTableSlot's reference
32 * to the tuple is dropped; while for a palloc'd tuple we usually want the
33 * tuple pfree'd when the TupleTableSlot's reference is dropped.
34 *
35 * A "minimal" tuple is handled similarly to a palloc'd regular tuple.
36 * At present, minimal tuples never are stored in buffers, so there is no
37 * parallel to case 1. Note that a minimal tuple has no "system columns".
38 * (Actually, it could have an OID, but we have no need to access the OID.)
39 *
40 * A "virtual" tuple is an optimization used to minimize physical data
41 * copying in a nest of plan nodes. Any pass-by-reference Datums in the
42 * tuple point to storage that is not directly associated with the
43 * TupleTableSlot; generally they will point to part of a tuple stored in
44 * a lower plan node's output TupleTableSlot, or to a function result
45 * constructed in a plan node's per-tuple econtext. It is the responsibility
46 * of the generating plan node to be sure these resources are not released
47 * for as long as the virtual tuple needs to be valid. We only use virtual
48 * tuples in the result slots of plan nodes --- tuples to be copied anywhere
49 * else need to be "materialized" into physical tuples. Note also that a
50 * virtual tuple does not have any "system columns".
51 *
52 * The Datum/isnull arrays of a TupleTableSlot serve double duty. When the
53 * slot contains a virtual tuple, they are the authoritative data. When the
54 * slot contains a physical tuple, the arrays contain data extracted from
55 * the tuple. (In this state, any pass-by-reference Datums point into
56 * the physical tuple.) The extracted information is built "lazily",
57 * ie, only as needed. This serves to avoid repeated extraction of data
58 * from the physical tuple.
59 *
60 * A TupleTableSlot can also be "empty", holding no valid data. This is
61 * the only valid state for a freshly-created slot that has not yet had a
62 * tuple descriptor assigned to it. In this state, tts_isempty must be
63 * TRUE, tts_shouldFree FALSE, tts_tuple NULL, tts_buffer InvalidBuffer,
64 * and tts_nvalid zero.
65 *
66 * The tupleDescriptor is simply referenced, not copied, by the TupleTableSlot
67 * code. The caller of ExecSetSlotDescriptor() is responsible for providing
68 * a descriptor that will live as long as the slot does. (Typically, both
69 * slots and descriptors are in per-query memory and are freed by memory
70 * context deallocation at query end; so it's not worth providing any extra
71 * mechanism to do more. However, the slot will increment the tupdesc
72 * reference count if a reference-counted tupdesc is supplied.)
73 *
74 * When tts_shouldFree is true, the physical tuple is "owned" by the slot
75 * and should be freed when the slot's reference to the tuple is dropped.
76 *
77 * If tts_buffer is not InvalidBuffer, then the slot is holding a pin
78 * on the indicated buffer page; drop the pin when we release the
79 * slot's reference to that buffer. (tts_shouldFree should always be
80 * false in such a case, since presumably tts_tuple is pointing at the
81 * buffer page.)
82 *
83 * tts_nvalid indicates the number of valid columns in the tts_values/isnull
84 * arrays. When the slot is holding a "virtual" tuple this must be equal
85 * to the descriptor's natts. When the slot is holding a physical tuple
86 * this is equal to the number of columns we have extracted (we always
87 * extract columns from left to right, so there are no holes).
88 *
89 * tts_values/tts_isnull are allocated when a descriptor is assigned to the
90 * slot; they are of length equal to the descriptor's natts.
91 *
92 * tts_mintuple must always be NULL if the slot does not hold a "minimal"
93 * tuple. When it does, tts_mintuple points to the actual MinimalTupleData
94 * object (the thing to be pfree'd if tts_shouldFree is true). In this case
95 * tts_tuple points at tts_minhdr and the fields of that are set correctly
96 * for access to the minimal tuple; in particular, tts_minhdr.t_data points
97 * MINIMAL_TUPLE_OFFSET bytes before tts_mintuple. (tts_mintuple is therefore
98 * redundant, but for code simplicity we store it explicitly anyway.) This
99 * case otherwise behaves identically to the regular-physical-tuple case.
100 *
101 * tts_slow/tts_off are saved state for slot_deform_tuple, and should not
102 * be touched by any other code.
103 *----------
104 */
106 {
123 /*
124 * Tuple table data structure: an array of TupleTableSlots.
125 */
127 {
136 /*
137 * TupIsNull -- is a TupleTableSlot empty?
138 */
139 #define TupIsNull(slot) \
140 ((slot) == NULL || (slot)->tts_isempty)
142 /* in executor/execTuples.c */
151 Buffer buffer,
167 /* in access/common/heaptuple.c */