firtst release
修订版 | eec77144accccf67006402fb1ac85a3e5d69f3d8 (tree) |
---|---|
时间 | 2014-01-17 11:49:38 |
作者 | Takashi Suzuki <suzuki.takashi@metr...> |
Commiter | Takashi Suzuki |
コピーライトを更新した
@@ -1,4 +1,4 @@ | ||
1 | -Copyright (c) 2012-2013, NIPPON TELEGRAPH AND TELEPHONE CORPORATION | |
1 | +Copyright (c) 2012-2014, NIPPON TELEGRAPH AND TELEPHONE CORPORATION | |
2 | 2 | All rights reserved. |
3 | 3 | |
4 | 4 | Redistribution and use in source and binary forms, with or without |
@@ -2,7 +2,7 @@ core.c and make_join_rel.c are parts of PostgreSQL Database Management System. | ||
2 | 2 | (formerly known as Postgres, then as Postgres95) |
3 | 3 | Copyright holders of those files are following organizations: |
4 | 4 | |
5 | -Portions Copyright (c) 1996-2013, PostgreSQL Global Development Group | |
5 | +Portions Copyright (c) 1996-2014, PostgreSQL Global Development Group | |
6 | 6 | |
7 | 7 | Portions Copyright (c) 1994, The Regents of the University of California |
8 | 8 |
@@ -1,7 +1,7 @@ | ||
1 | 1 | # |
2 | 2 | # pg_hint_plan: Makefile |
3 | 3 | # |
4 | -# Copyright (c) 2012-2013, NIPPON TELEGRAPH AND TELEPHONE CORPORATION | |
4 | +# Copyright (c) 2012-2014, NIPPON TELEGRAPH AND TELEPHONE CORPORATION | |
5 | 5 | # |
6 | 6 | |
7 | 7 | MODULES = pg_hint_plan |
@@ -1,5 +1,5 @@ | ||
1 | 1 | # SPEC file for pg_hint_plan |
2 | -# Copyright(C) 2013 NIPPON TELEGRAPH AND TELEPHONE CORPORATION | |
2 | +# Copyright(C) 2012-2014 NIPPON TELEGRAPH AND TELEPHONE CORPORATION | |
3 | 3 | |
4 | 4 | %define _pgdir /usr/pgsql-9.3 |
5 | 5 | %define _bindir %{_pgdir}/bin |
@@ -20,7 +20,7 @@ | ||
20 | 20 | * mark_dummy_rel() |
21 | 21 | * restriction_is_constant_false() |
22 | 22 | * |
23 | - * Portions Copyright (c) 1996-2013, PostgreSQL Global Development Group | |
23 | + * Portions Copyright (c) 1996-2014, PostgreSQL Global Development Group | |
24 | 24 | * Portions Copyright (c) 1994, Regents of the University of California |
25 | 25 | * |
26 | 26 | *------------------------------------------------------------------------- |
@@ -1,710 +0,0 @@ | ||
1 | -/*------------------------------------------------------------------------- | |
2 | - * | |
3 | - * htup_details.h | |
4 | - * POSTGRES heap tuple header definitions. | |
5 | - * | |
6 | - * | |
7 | - * Portions Copyright (c) 1996-2013, PostgreSQL Global Development Group | |
8 | - * Portions Copyright (c) 1994, Regents of the University of California | |
9 | - * | |
10 | - * src/include/access/htup_details.h | |
11 | - * | |
12 | - *------------------------------------------------------------------------- | |
13 | - */ | |
14 | -#ifndef HTUP_DETAILS_H | |
15 | -#define HTUP_DETAILS_H | |
16 | - | |
17 | -#include "access/htup.h" | |
18 | -#include "access/tupdesc.h" | |
19 | -#include "access/tupmacs.h" | |
20 | -#include "storage/bufpage.h" | |
21 | - | |
22 | -/* | |
23 | - * MaxTupleAttributeNumber limits the number of (user) columns in a tuple. | |
24 | - * The key limit on this value is that the size of the fixed overhead for | |
25 | - * a tuple, plus the size of the null-values bitmap (at 1 bit per column), | |
26 | - * plus MAXALIGN alignment, must fit into t_hoff which is uint8. On most | |
27 | - * machines the upper limit without making t_hoff wider would be a little | |
28 | - * over 1700. We use round numbers here and for MaxHeapAttributeNumber | |
29 | - * so that alterations in HeapTupleHeaderData layout won't change the | |
30 | - * supported max number of columns. | |
31 | - */ | |
32 | -#define MaxTupleAttributeNumber 1664 /* 8 * 208 */ | |
33 | - | |
34 | -/* | |
35 | - * MaxHeapAttributeNumber limits the number of (user) columns in a table. | |
36 | - * This should be somewhat less than MaxTupleAttributeNumber. It must be | |
37 | - * at least one less, else we will fail to do UPDATEs on a maximal-width | |
38 | - * table (because UPDATE has to form working tuples that include CTID). | |
39 | - * In practice we want some additional daylight so that we can gracefully | |
40 | - * support operations that add hidden "resjunk" columns, for example | |
41 | - * SELECT * FROM wide_table ORDER BY foo, bar, baz. | |
42 | - * In any case, depending on column data types you will likely be running | |
43 | - * into the disk-block-based limit on overall tuple size if you have more | |
44 | - * than a thousand or so columns. TOAST won't help. | |
45 | - */ | |
46 | -#define MaxHeapAttributeNumber 1600 /* 8 * 200 */ | |
47 | - | |
48 | -/* | |
49 | - * Heap tuple header. To avoid wasting space, the fields should be | |
50 | - * laid out in such a way as to avoid structure padding. | |
51 | - * | |
52 | - * Datums of composite types (row types) share the same general structure | |
53 | - * as on-disk tuples, so that the same routines can be used to build and | |
54 | - * examine them. However the requirements are slightly different: a Datum | |
55 | - * does not need any transaction visibility information, and it does need | |
56 | - * a length word and some embedded type information. We can achieve this | |
57 | - * by overlaying the xmin/cmin/xmax/cmax/xvac fields of a heap tuple | |
58 | - * with the fields needed in the Datum case. Typically, all tuples built | |
59 | - * in-memory will be initialized with the Datum fields; but when a tuple is | |
60 | - * about to be inserted in a table, the transaction fields will be filled, | |
61 | - * overwriting the datum fields. | |
62 | - * | |
63 | - * The overall structure of a heap tuple looks like: | |
64 | - * fixed fields (HeapTupleHeaderData struct) | |
65 | - * nulls bitmap (if HEAP_HASNULL is set in t_infomask) | |
66 | - * alignment padding (as needed to make user data MAXALIGN'd) | |
67 | - * object ID (if HEAP_HASOID is set in t_infomask) | |
68 | - * user data fields | |
69 | - * | |
70 | - * We store five "virtual" fields Xmin, Cmin, Xmax, Cmax, and Xvac in three | |
71 | - * physical fields. Xmin and Xmax are always really stored, but Cmin, Cmax | |
72 | - * and Xvac share a field. This works because we know that Cmin and Cmax | |
73 | - * are only interesting for the lifetime of the inserting and deleting | |
74 | - * transaction respectively. If a tuple is inserted and deleted in the same | |
75 | - * transaction, we store a "combo" command id that can be mapped to the real | |
76 | - * cmin and cmax, but only by use of local state within the originating | |
77 | - * backend. See combocid.c for more details. Meanwhile, Xvac is only set by | |
78 | - * old-style VACUUM FULL, which does not have any command sub-structure and so | |
79 | - * does not need either Cmin or Cmax. (This requires that old-style VACUUM | |
80 | - * FULL never try to move a tuple whose Cmin or Cmax is still interesting, | |
81 | - * ie, an insert-in-progress or delete-in-progress tuple.) | |
82 | - * | |
83 | - * A word about t_ctid: whenever a new tuple is stored on disk, its t_ctid | |
84 | - * is initialized with its own TID (location). If the tuple is ever updated, | |
85 | - * its t_ctid is changed to point to the replacement version of the tuple. | |
86 | - * Thus, a tuple is the latest version of its row iff XMAX is invalid or | |
87 | - * t_ctid points to itself (in which case, if XMAX is valid, the tuple is | |
88 | - * either locked or deleted). One can follow the chain of t_ctid links | |
89 | - * to find the newest version of the row. Beware however that VACUUM might | |
90 | - * erase the pointed-to (newer) tuple before erasing the pointing (older) | |
91 | - * tuple. Hence, when following a t_ctid link, it is necessary to check | |
92 | - * to see if the referenced slot is empty or contains an unrelated tuple. | |
93 | - * Check that the referenced tuple has XMIN equal to the referencing tuple's | |
94 | - * XMAX to verify that it is actually the descendant version and not an | |
95 | - * unrelated tuple stored into a slot recently freed by VACUUM. If either | |
96 | - * check fails, one may assume that there is no live descendant version. | |
97 | - * | |
98 | - * Following the fixed header fields, the nulls bitmap is stored (beginning | |
99 | - * at t_bits). The bitmap is *not* stored if t_infomask shows that there | |
100 | - * are no nulls in the tuple. If an OID field is present (as indicated by | |
101 | - * t_infomask), then it is stored just before the user data, which begins at | |
102 | - * the offset shown by t_hoff. Note that t_hoff must be a multiple of | |
103 | - * MAXALIGN. | |
104 | - */ | |
105 | - | |
106 | -typedef struct HeapTupleFields | |
107 | -{ | |
108 | - TransactionId t_xmin; /* inserting xact ID */ | |
109 | - TransactionId t_xmax; /* deleting or locking xact ID */ | |
110 | - | |
111 | - union | |
112 | - { | |
113 | - CommandId t_cid; /* inserting or deleting command ID, or both */ | |
114 | - TransactionId t_xvac; /* old-style VACUUM FULL xact ID */ | |
115 | - } t_field3; | |
116 | -} HeapTupleFields; | |
117 | - | |
118 | -typedef struct DatumTupleFields | |
119 | -{ | |
120 | - int32 datum_len_; /* varlena header (do not touch directly!) */ | |
121 | - | |
122 | - int32 datum_typmod; /* -1, or identifier of a record type */ | |
123 | - | |
124 | - Oid datum_typeid; /* composite type OID, or RECORDOID */ | |
125 | - | |
126 | - /* | |
127 | - * Note: field ordering is chosen with thought that Oid might someday | |
128 | - * widen to 64 bits. | |
129 | - */ | |
130 | -} DatumTupleFields; | |
131 | - | |
132 | -struct HeapTupleHeaderData | |
133 | -{ | |
134 | - union | |
135 | - { | |
136 | - HeapTupleFields t_heap; | |
137 | - DatumTupleFields t_datum; | |
138 | - } t_choice; | |
139 | - | |
140 | - ItemPointerData t_ctid; /* current TID of this or newer tuple */ | |
141 | - | |
142 | - /* Fields below here must match MinimalTupleData! */ | |
143 | - | |
144 | - uint16 t_infomask2; /* number of attributes + various flags */ | |
145 | - | |
146 | - uint16 t_infomask; /* various flag bits, see below */ | |
147 | - | |
148 | - uint8 t_hoff; /* sizeof header incl. bitmap, padding */ | |
149 | - | |
150 | - /* ^ - 23 bytes - ^ */ | |
151 | - | |
152 | - bits8 t_bits[1]; /* bitmap of NULLs -- VARIABLE LENGTH */ | |
153 | - | |
154 | - /* MORE DATA FOLLOWS AT END OF STRUCT */ | |
155 | -}; | |
156 | - | |
157 | -/* typedef appears in tupbasics.h */ | |
158 | - | |
159 | -/* | |
160 | - * information stored in t_infomask: | |
161 | - */ | |
162 | -#define HEAP_HASNULL 0x0001 /* has null attribute(s) */ | |
163 | -#define HEAP_HASVARWIDTH 0x0002 /* has variable-width attribute(s) */ | |
164 | -#define HEAP_HASEXTERNAL 0x0004 /* has external stored attribute(s) */ | |
165 | -#define HEAP_HASOID 0x0008 /* has an object-id field */ | |
166 | -#define HEAP_XMAX_KEYSHR_LOCK 0x0010 /* xmax is a key-shared locker */ | |
167 | -#define HEAP_COMBOCID 0x0020 /* t_cid is a combo cid */ | |
168 | -#define HEAP_XMAX_EXCL_LOCK 0x0040 /* xmax is exclusive locker */ | |
169 | -#define HEAP_XMAX_LOCK_ONLY 0x0080 /* xmax, if valid, is only a locker */ | |
170 | - | |
171 | - /* xmax is a shared locker */ | |
172 | -#define HEAP_XMAX_SHR_LOCK (HEAP_XMAX_EXCL_LOCK | HEAP_XMAX_KEYSHR_LOCK) | |
173 | - | |
174 | -#define HEAP_LOCK_MASK (HEAP_XMAX_SHR_LOCK | HEAP_XMAX_EXCL_LOCK | \ | |
175 | - HEAP_XMAX_KEYSHR_LOCK) | |
176 | -#define HEAP_XMIN_COMMITTED 0x0100 /* t_xmin committed */ | |
177 | -#define HEAP_XMIN_INVALID 0x0200 /* t_xmin invalid/aborted */ | |
178 | -#define HEAP_XMAX_COMMITTED 0x0400 /* t_xmax committed */ | |
179 | -#define HEAP_XMAX_INVALID 0x0800 /* t_xmax invalid/aborted */ | |
180 | -#define HEAP_XMAX_IS_MULTI 0x1000 /* t_xmax is a MultiXactId */ | |
181 | -#define HEAP_UPDATED 0x2000 /* this is UPDATEd version of row */ | |
182 | -#define HEAP_MOVED_OFF 0x4000 /* moved to another place by pre-9.0 | |
183 | - * VACUUM FULL; kept for binary | |
184 | - * upgrade support */ | |
185 | -#define HEAP_MOVED_IN 0x8000 /* moved from another place by pre-9.0 | |
186 | - * VACUUM FULL; kept for binary | |
187 | - * upgrade support */ | |
188 | -#define HEAP_MOVED (HEAP_MOVED_OFF | HEAP_MOVED_IN) | |
189 | - | |
190 | -#define HEAP_XACT_MASK 0xFFF0 /* visibility-related bits */ | |
191 | - | |
192 | -/* | |
193 | - * A tuple is only locked (i.e. not updated by its Xmax) if the | |
194 | - * HEAP_XMAX_LOCK_ONLY bit is set; or, for pg_upgrade's sake, if the Xmax is | |
195 | - * not a multi and the EXCL_LOCK bit is set. | |
196 | - * | |
197 | - * See also HeapTupleHeaderIsOnlyLocked, which also checks for a possible | |
198 | - * aborted updater transaction. | |
199 | - * | |
200 | - * Beware of multiple evaluations of the argument. | |
201 | - */ | |
202 | -#define HEAP_XMAX_IS_LOCKED_ONLY(infomask) \ | |
203 | - (((infomask) & HEAP_XMAX_LOCK_ONLY) || \ | |
204 | - (((infomask) & (HEAP_XMAX_IS_MULTI | HEAP_LOCK_MASK)) == HEAP_XMAX_EXCL_LOCK)) | |
205 | - | |
206 | -/* | |
207 | - * Use these to test whether a particular lock is applied to a tuple | |
208 | - */ | |
209 | -#define HEAP_XMAX_IS_SHR_LOCKED(infomask) \ | |
210 | - (((infomask) & HEAP_LOCK_MASK) == HEAP_XMAX_SHR_LOCK) | |
211 | -#define HEAP_XMAX_IS_EXCL_LOCKED(infomask) \ | |
212 | - (((infomask) & HEAP_LOCK_MASK) == HEAP_XMAX_EXCL_LOCK) | |
213 | -#define HEAP_XMAX_IS_KEYSHR_LOCKED(infomask) \ | |
214 | - (((infomask) & HEAP_LOCK_MASK) == HEAP_XMAX_KEYSHR_LOCK) | |
215 | - | |
216 | -/* turn these all off when Xmax is to change */ | |
217 | -#define HEAP_XMAX_BITS (HEAP_XMAX_COMMITTED | HEAP_XMAX_INVALID | \ | |
218 | - HEAP_XMAX_IS_MULTI | HEAP_LOCK_MASK | HEAP_XMAX_LOCK_ONLY) | |
219 | - | |
220 | -/* | |
221 | - * information stored in t_infomask2: | |
222 | - */ | |
223 | -#define HEAP_NATTS_MASK 0x07FF /* 11 bits for number of attributes */ | |
224 | -/* bits 0x1800 are available */ | |
225 | -#define HEAP_KEYS_UPDATED 0x2000 /* tuple was updated and key cols | |
226 | - * modified, or tuple deleted */ | |
227 | -#define HEAP_HOT_UPDATED 0x4000 /* tuple was HOT-updated */ | |
228 | -#define HEAP_ONLY_TUPLE 0x8000 /* this is heap-only tuple */ | |
229 | - | |
230 | -#define HEAP2_XACT_MASK 0xE000 /* visibility-related bits */ | |
231 | - | |
232 | -/* | |
233 | - * HEAP_TUPLE_HAS_MATCH is a temporary flag used during hash joins. It is | |
234 | - * only used in tuples that are in the hash table, and those don't need | |
235 | - * any visibility information, so we can overlay it on a visibility flag | |
236 | - * instead of using up a dedicated bit. | |
237 | - */ | |
238 | -#define HEAP_TUPLE_HAS_MATCH HEAP_ONLY_TUPLE /* tuple has a join match */ | |
239 | - | |
240 | -/* | |
241 | - * HeapTupleHeader accessor macros | |
242 | - * | |
243 | - * Note: beware of multiple evaluations of "tup" argument. But the Set | |
244 | - * macros evaluate their other argument only once. | |
245 | - */ | |
246 | - | |
247 | -#define HeapTupleHeaderGetXmin(tup) \ | |
248 | -( \ | |
249 | - (tup)->t_choice.t_heap.t_xmin \ | |
250 | -) | |
251 | - | |
252 | -#define HeapTupleHeaderSetXmin(tup, xid) \ | |
253 | -( \ | |
254 | - (tup)->t_choice.t_heap.t_xmin = (xid) \ | |
255 | -) | |
256 | - | |
257 | -/* | |
258 | - * HeapTupleHeaderGetRawXmax gets you the raw Xmax field. To find out the Xid | |
259 | - * that updated a tuple, you might need to resolve the MultiXactId if certain | |
260 | - * bits are set. HeapTupleHeaderGetUpdateXid checks those bits and takes care | |
261 | - * to resolve the MultiXactId if necessary. This might involve multixact I/O, | |
262 | - * so it should only be used if absolutely necessary. | |
263 | - */ | |
264 | -#define HeapTupleHeaderGetUpdateXid(tup) \ | |
265 | -( \ | |
266 | - (!((tup)->t_infomask & HEAP_XMAX_INVALID) && \ | |
267 | - ((tup)->t_infomask & HEAP_XMAX_IS_MULTI) && \ | |
268 | - !((tup)->t_infomask & HEAP_XMAX_LOCK_ONLY)) ? \ | |
269 | - HeapTupleGetUpdateXid(tup) \ | |
270 | - : \ | |
271 | - HeapTupleHeaderGetRawXmax(tup) \ | |
272 | -) | |
273 | - | |
274 | -#define HeapTupleHeaderGetRawXmax(tup) \ | |
275 | -( \ | |
276 | - (tup)->t_choice.t_heap.t_xmax \ | |
277 | -) | |
278 | - | |
279 | -#define HeapTupleHeaderSetXmax(tup, xid) \ | |
280 | -( \ | |
281 | - (tup)->t_choice.t_heap.t_xmax = (xid) \ | |
282 | -) | |
283 | - | |
284 | -/* | |
285 | - * HeapTupleHeaderGetRawCommandId will give you what's in the header whether | |
286 | - * it is useful or not. Most code should use HeapTupleHeaderGetCmin or | |
287 | - * HeapTupleHeaderGetCmax instead, but note that those Assert that you can | |
288 | - * get a legitimate result, ie you are in the originating transaction! | |
289 | - */ | |
290 | -#define HeapTupleHeaderGetRawCommandId(tup) \ | |
291 | -( \ | |
292 | - (tup)->t_choice.t_heap.t_field3.t_cid \ | |
293 | -) | |
294 | - | |
295 | -/* SetCmin is reasonably simple since we never need a combo CID */ | |
296 | -#define HeapTupleHeaderSetCmin(tup, cid) \ | |
297 | -do { \ | |
298 | - Assert(!((tup)->t_infomask & HEAP_MOVED)); \ | |
299 | - (tup)->t_choice.t_heap.t_field3.t_cid = (cid); \ | |
300 | - (tup)->t_infomask &= ~HEAP_COMBOCID; \ | |
301 | -} while (0) | |
302 | - | |
303 | -/* SetCmax must be used after HeapTupleHeaderAdjustCmax; see combocid.c */ | |
304 | -#define HeapTupleHeaderSetCmax(tup, cid, iscombo) \ | |
305 | -do { \ | |
306 | - Assert(!((tup)->t_infomask & HEAP_MOVED)); \ | |
307 | - (tup)->t_choice.t_heap.t_field3.t_cid = (cid); \ | |
308 | - if (iscombo) \ | |
309 | - (tup)->t_infomask |= HEAP_COMBOCID; \ | |
310 | - else \ | |
311 | - (tup)->t_infomask &= ~HEAP_COMBOCID; \ | |
312 | -} while (0) | |
313 | - | |
314 | -#define HeapTupleHeaderGetXvac(tup) \ | |
315 | -( \ | |
316 | - ((tup)->t_infomask & HEAP_MOVED) ? \ | |
317 | - (tup)->t_choice.t_heap.t_field3.t_xvac \ | |
318 | - : \ | |
319 | - InvalidTransactionId \ | |
320 | -) | |
321 | - | |
322 | -#define HeapTupleHeaderSetXvac(tup, xid) \ | |
323 | -do { \ | |
324 | - Assert((tup)->t_infomask & HEAP_MOVED); \ | |
325 | - (tup)->t_choice.t_heap.t_field3.t_xvac = (xid); \ | |
326 | -} while (0) | |
327 | - | |
328 | -#define HeapTupleHeaderGetDatumLength(tup) \ | |
329 | - VARSIZE(tup) | |
330 | - | |
331 | -#define HeapTupleHeaderSetDatumLength(tup, len) \ | |
332 | - SET_VARSIZE(tup, len) | |
333 | - | |
334 | -#define HeapTupleHeaderGetTypeId(tup) \ | |
335 | -( \ | |
336 | - (tup)->t_choice.t_datum.datum_typeid \ | |
337 | -) | |
338 | - | |
339 | -#define HeapTupleHeaderSetTypeId(tup, typeid) \ | |
340 | -( \ | |
341 | - (tup)->t_choice.t_datum.datum_typeid = (typeid) \ | |
342 | -) | |
343 | - | |
344 | -#define HeapTupleHeaderGetTypMod(tup) \ | |
345 | -( \ | |
346 | - (tup)->t_choice.t_datum.datum_typmod \ | |
347 | -) | |
348 | - | |
349 | -#define HeapTupleHeaderSetTypMod(tup, typmod) \ | |
350 | -( \ | |
351 | - (tup)->t_choice.t_datum.datum_typmod = (typmod) \ | |
352 | -) | |
353 | - | |
354 | -#define HeapTupleHeaderGetOid(tup) \ | |
355 | -( \ | |
356 | - ((tup)->t_infomask & HEAP_HASOID) ? \ | |
357 | - *((Oid *) ((char *)(tup) + (tup)->t_hoff - sizeof(Oid))) \ | |
358 | - : \ | |
359 | - InvalidOid \ | |
360 | -) | |
361 | - | |
362 | -#define HeapTupleHeaderSetOid(tup, oid) \ | |
363 | -do { \ | |
364 | - Assert((tup)->t_infomask & HEAP_HASOID); \ | |
365 | - *((Oid *) ((char *)(tup) + (tup)->t_hoff - sizeof(Oid))) = (oid); \ | |
366 | -} while (0) | |
367 | - | |
368 | -/* | |
369 | - * Note that we stop considering a tuple HOT-updated as soon as it is known | |
370 | - * aborted or the would-be updating transaction is known aborted. For best | |
371 | - * efficiency, check tuple visibility before using this macro, so that the | |
372 | - * INVALID bits will be as up to date as possible. | |
373 | - */ | |
374 | -#define HeapTupleHeaderIsHotUpdated(tup) \ | |
375 | -( \ | |
376 | - ((tup)->t_infomask2 & HEAP_HOT_UPDATED) != 0 && \ | |
377 | - ((tup)->t_infomask & (HEAP_XMIN_INVALID | HEAP_XMAX_INVALID)) == 0 \ | |
378 | -) | |
379 | - | |
380 | -#define HeapTupleHeaderSetHotUpdated(tup) \ | |
381 | -( \ | |
382 | - (tup)->t_infomask2 |= HEAP_HOT_UPDATED \ | |
383 | -) | |
384 | - | |
385 | -#define HeapTupleHeaderClearHotUpdated(tup) \ | |
386 | -( \ | |
387 | - (tup)->t_infomask2 &= ~HEAP_HOT_UPDATED \ | |
388 | -) | |
389 | - | |
390 | -#define HeapTupleHeaderIsHeapOnly(tup) \ | |
391 | -( \ | |
392 | - (tup)->t_infomask2 & HEAP_ONLY_TUPLE \ | |
393 | -) | |
394 | - | |
395 | -#define HeapTupleHeaderSetHeapOnly(tup) \ | |
396 | -( \ | |
397 | - (tup)->t_infomask2 |= HEAP_ONLY_TUPLE \ | |
398 | -) | |
399 | - | |
400 | -#define HeapTupleHeaderClearHeapOnly(tup) \ | |
401 | -( \ | |
402 | - (tup)->t_infomask2 &= ~HEAP_ONLY_TUPLE \ | |
403 | -) | |
404 | - | |
405 | -#define HeapTupleHeaderHasMatch(tup) \ | |
406 | -( \ | |
407 | - (tup)->t_infomask2 & HEAP_TUPLE_HAS_MATCH \ | |
408 | -) | |
409 | - | |
410 | -#define HeapTupleHeaderSetMatch(tup) \ | |
411 | -( \ | |
412 | - (tup)->t_infomask2 |= HEAP_TUPLE_HAS_MATCH \ | |
413 | -) | |
414 | - | |
415 | -#define HeapTupleHeaderClearMatch(tup) \ | |
416 | -( \ | |
417 | - (tup)->t_infomask2 &= ~HEAP_TUPLE_HAS_MATCH \ | |
418 | -) | |
419 | - | |
420 | -#define HeapTupleHeaderGetNatts(tup) \ | |
421 | - ((tup)->t_infomask2 & HEAP_NATTS_MASK) | |
422 | - | |
423 | -#define HeapTupleHeaderSetNatts(tup, natts) \ | |
424 | -( \ | |
425 | - (tup)->t_infomask2 = ((tup)->t_infomask2 & ~HEAP_NATTS_MASK) | (natts) \ | |
426 | -) | |
427 | - | |
428 | - | |
429 | -/* | |
430 | - * BITMAPLEN(NATTS) - | |
431 | - * Computes size of null bitmap given number of data columns. | |
432 | - */ | |
433 | -#define BITMAPLEN(NATTS) (((int)(NATTS) + 7) / 8) | |
434 | - | |
435 | -/* | |
436 | - * MaxHeapTupleSize is the maximum allowed size of a heap tuple, including | |
437 | - * header and MAXALIGN alignment padding. Basically it's BLCKSZ minus the | |
438 | - * other stuff that has to be on a disk page. Since heap pages use no | |
439 | - * "special space", there's no deduction for that. | |
440 | - * | |
441 | - * NOTE: we allow for the ItemId that must point to the tuple, ensuring that | |
442 | - * an otherwise-empty page can indeed hold a tuple of this size. Because | |
443 | - * ItemIds and tuples have different alignment requirements, don't assume that | |
444 | - * you can, say, fit 2 tuples of size MaxHeapTupleSize/2 on the same page. | |
445 | - */ | |
446 | -#define MaxHeapTupleSize (BLCKSZ - MAXALIGN(SizeOfPageHeaderData + sizeof(ItemIdData))) | |
447 | - | |
448 | -/* | |
449 | - * MaxHeapTuplesPerPage is an upper bound on the number of tuples that can | |
450 | - * fit on one heap page. (Note that indexes could have more, because they | |
451 | - * use a smaller tuple header.) We arrive at the divisor because each tuple | |
452 | - * must be maxaligned, and it must have an associated item pointer. | |
453 | - * | |
454 | - * Note: with HOT, there could theoretically be more line pointers (not actual | |
455 | - * tuples) than this on a heap page. However we constrain the number of line | |
456 | - * pointers to this anyway, to avoid excessive line-pointer bloat and not | |
457 | - * require increases in the size of work arrays. | |
458 | - */ | |
459 | -#define MaxHeapTuplesPerPage \ | |
460 | - ((int) ((BLCKSZ - SizeOfPageHeaderData) / \ | |
461 | - (MAXALIGN(offsetof(HeapTupleHeaderData, t_bits)) + sizeof(ItemIdData)))) | |
462 | - | |
463 | -/* | |
464 | - * MaxAttrSize is a somewhat arbitrary upper limit on the declared size of | |
465 | - * data fields of char(n) and similar types. It need not have anything | |
466 | - * directly to do with the *actual* upper limit of varlena values, which | |
467 | - * is currently 1Gb (see TOAST structures in postgres.h). I've set it | |
468 | - * at 10Mb which seems like a reasonable number --- tgl 8/6/00. | |
469 | - */ | |
470 | -#define MaxAttrSize (10 * 1024 * 1024) | |
471 | - | |
472 | - | |
473 | -/* | |
474 | - * MinimalTuple is an alternative representation that is used for transient | |
475 | - * tuples inside the executor, in places where transaction status information | |
476 | - * is not required, the tuple rowtype is known, and shaving off a few bytes | |
477 | - * is worthwhile because we need to store many tuples. The representation | |
478 | - * is chosen so that tuple access routines can work with either full or | |
479 | - * minimal tuples via a HeapTupleData pointer structure. The access routines | |
480 | - * see no difference, except that they must not access the transaction status | |
481 | - * or t_ctid fields because those aren't there. | |
482 | - * | |
483 | - * For the most part, MinimalTuples should be accessed via TupleTableSlot | |
484 | - * routines. These routines will prevent access to the "system columns" | |
485 | - * and thereby prevent accidental use of the nonexistent fields. | |
486 | - * | |
487 | - * MinimalTupleData contains a length word, some padding, and fields matching | |
488 | - * HeapTupleHeaderData beginning with t_infomask2. The padding is chosen so | |
489 | - * that offsetof(t_infomask2) is the same modulo MAXIMUM_ALIGNOF in both | |
490 | - * structs. This makes data alignment rules equivalent in both cases. | |
491 | - * | |
492 | - * When a minimal tuple is accessed via a HeapTupleData pointer, t_data is | |
493 | - * set to point MINIMAL_TUPLE_OFFSET bytes before the actual start of the | |
494 | - * minimal tuple --- that is, where a full tuple matching the minimal tuple's | |
495 | - * data would start. This trick is what makes the structs seem equivalent. | |
496 | - * | |
497 | - * Note that t_hoff is computed the same as in a full tuple, hence it includes | |
498 | - * the MINIMAL_TUPLE_OFFSET distance. t_len does not include that, however. | |
499 | - * | |
500 | - * MINIMAL_TUPLE_DATA_OFFSET is the offset to the first useful (non-pad) data | |
501 | - * other than the length word. tuplesort.c and tuplestore.c use this to avoid | |
502 | - * writing the padding to disk. | |
503 | - */ | |
504 | -#define MINIMAL_TUPLE_OFFSET \ | |
505 | - ((offsetof(HeapTupleHeaderData, t_infomask2) - sizeof(uint32)) / MAXIMUM_ALIGNOF * MAXIMUM_ALIGNOF) | |
506 | -#define MINIMAL_TUPLE_PADDING \ | |
507 | - ((offsetof(HeapTupleHeaderData, t_infomask2) - sizeof(uint32)) % MAXIMUM_ALIGNOF) | |
508 | -#define MINIMAL_TUPLE_DATA_OFFSET \ | |
509 | - offsetof(MinimalTupleData, t_infomask2) | |
510 | - | |
511 | -struct MinimalTupleData | |
512 | -{ | |
513 | - uint32 t_len; /* actual length of minimal tuple */ | |
514 | - | |
515 | - char mt_padding[MINIMAL_TUPLE_PADDING]; | |
516 | - | |
517 | - /* Fields below here must match HeapTupleHeaderData! */ | |
518 | - | |
519 | - uint16 t_infomask2; /* number of attributes + various flags */ | |
520 | - | |
521 | - uint16 t_infomask; /* various flag bits, see below */ | |
522 | - | |
523 | - uint8 t_hoff; /* sizeof header incl. bitmap, padding */ | |
524 | - | |
525 | - /* ^ - 23 bytes - ^ */ | |
526 | - | |
527 | - bits8 t_bits[1]; /* bitmap of NULLs -- VARIABLE LENGTH */ | |
528 | - | |
529 | - /* MORE DATA FOLLOWS AT END OF STRUCT */ | |
530 | -}; | |
531 | - | |
532 | -/* typedef appears in htup.h */ | |
533 | - | |
534 | - | |
535 | -/* | |
536 | - * GETSTRUCT - given a HeapTuple pointer, return address of the user data | |
537 | - */ | |
538 | -#define GETSTRUCT(TUP) ((char *) ((TUP)->t_data) + (TUP)->t_data->t_hoff) | |
539 | - | |
540 | -/* | |
541 | - * Accessor macros to be used with HeapTuple pointers. | |
542 | - */ | |
543 | - | |
544 | -#define HeapTupleHasNulls(tuple) \ | |
545 | - (((tuple)->t_data->t_infomask & HEAP_HASNULL) != 0) | |
546 | - | |
547 | -#define HeapTupleNoNulls(tuple) \ | |
548 | - (!((tuple)->t_data->t_infomask & HEAP_HASNULL)) | |
549 | - | |
550 | -#define HeapTupleHasVarWidth(tuple) \ | |
551 | - (((tuple)->t_data->t_infomask & HEAP_HASVARWIDTH) != 0) | |
552 | - | |
553 | -#define HeapTupleAllFixed(tuple) \ | |
554 | - (!((tuple)->t_data->t_infomask & HEAP_HASVARWIDTH)) | |
555 | - | |
556 | -#define HeapTupleHasExternal(tuple) \ | |
557 | - (((tuple)->t_data->t_infomask & HEAP_HASEXTERNAL) != 0) | |
558 | - | |
559 | -#define HeapTupleIsHotUpdated(tuple) \ | |
560 | - HeapTupleHeaderIsHotUpdated((tuple)->t_data) | |
561 | - | |
562 | -#define HeapTupleSetHotUpdated(tuple) \ | |
563 | - HeapTupleHeaderSetHotUpdated((tuple)->t_data) | |
564 | - | |
565 | -#define HeapTupleClearHotUpdated(tuple) \ | |
566 | - HeapTupleHeaderClearHotUpdated((tuple)->t_data) | |
567 | - | |
568 | -#define HeapTupleIsHeapOnly(tuple) \ | |
569 | - HeapTupleHeaderIsHeapOnly((tuple)->t_data) | |
570 | - | |
571 | -#define HeapTupleSetHeapOnly(tuple) \ | |
572 | - HeapTupleHeaderSetHeapOnly((tuple)->t_data) | |
573 | - | |
574 | -#define HeapTupleClearHeapOnly(tuple) \ | |
575 | - HeapTupleHeaderClearHeapOnly((tuple)->t_data) | |
576 | - | |
577 | -#define HeapTupleGetOid(tuple) \ | |
578 | - HeapTupleHeaderGetOid((tuple)->t_data) | |
579 | - | |
580 | -#define HeapTupleSetOid(tuple, oid) \ | |
581 | - HeapTupleHeaderSetOid((tuple)->t_data, (oid)) | |
582 | - | |
583 | - | |
584 | -/* ---------------- | |
585 | - * fastgetattr | |
586 | - * | |
587 | - * Fetch a user attribute's value as a Datum (might be either a | |
588 | - * value, or a pointer into the data area of the tuple). | |
589 | - * | |
590 | - * This must not be used when a system attribute might be requested. | |
591 | - * Furthermore, the passed attnum MUST be valid. Use heap_getattr() | |
592 | - * instead, if in doubt. | |
593 | - * | |
594 | - * This gets called many times, so we macro the cacheable and NULL | |
595 | - * lookups, and call nocachegetattr() for the rest. | |
596 | - * ---------------- | |
597 | - */ | |
598 | - | |
599 | -#if !defined(DISABLE_COMPLEX_MACRO) | |
600 | - | |
601 | -#define fastgetattr(tup, attnum, tupleDesc, isnull) \ | |
602 | -( \ | |
603 | - AssertMacro((attnum) > 0), \ | |
604 | - (*(isnull) = false), \ | |
605 | - HeapTupleNoNulls(tup) ? \ | |
606 | - ( \ | |
607 | - (tupleDesc)->attrs[(attnum)-1]->attcacheoff >= 0 ? \ | |
608 | - ( \ | |
609 | - fetchatt((tupleDesc)->attrs[(attnum)-1], \ | |
610 | - (char *) (tup)->t_data + (tup)->t_data->t_hoff + \ | |
611 | - (tupleDesc)->attrs[(attnum)-1]->attcacheoff) \ | |
612 | - ) \ | |
613 | - : \ | |
614 | - nocachegetattr((tup), (attnum), (tupleDesc)) \ | |
615 | - ) \ | |
616 | - : \ | |
617 | - ( \ | |
618 | - att_isnull((attnum)-1, (tup)->t_data->t_bits) ? \ | |
619 | - ( \ | |
620 | - (*(isnull) = true), \ | |
621 | - (Datum)NULL \ | |
622 | - ) \ | |
623 | - : \ | |
624 | - ( \ | |
625 | - nocachegetattr((tup), (attnum), (tupleDesc)) \ | |
626 | - ) \ | |
627 | - ) \ | |
628 | -) | |
629 | -#else /* defined(DISABLE_COMPLEX_MACRO) */ | |
630 | - | |
631 | -extern Datum fastgetattr(HeapTuple tup, int attnum, TupleDesc tupleDesc, | |
632 | - bool *isnull); | |
633 | -#endif /* defined(DISABLE_COMPLEX_MACRO) */ | |
634 | - | |
635 | - | |
636 | -/* ---------------- | |
637 | - * heap_getattr | |
638 | - * | |
639 | - * Extract an attribute of a heap tuple and return it as a Datum. | |
640 | - * This works for either system or user attributes. The given attnum | |
641 | - * is properly range-checked. | |
642 | - * | |
643 | - * If the field in question has a NULL value, we return a zero Datum | |
644 | - * and set *isnull == true. Otherwise, we set *isnull == false. | |
645 | - * | |
646 | - * <tup> is the pointer to the heap tuple. <attnum> is the attribute | |
647 | - * number of the column (field) caller wants. <tupleDesc> is a | |
648 | - * pointer to the structure describing the row and all its fields. | |
649 | - * ---------------- | |
650 | - */ | |
651 | -#define heap_getattr(tup, attnum, tupleDesc, isnull) \ | |
652 | - ( \ | |
653 | - ((attnum) > 0) ? \ | |
654 | - ( \ | |
655 | - ((attnum) > (int) HeapTupleHeaderGetNatts((tup)->t_data)) ? \ | |
656 | - ( \ | |
657 | - (*(isnull) = true), \ | |
658 | - (Datum)NULL \ | |
659 | - ) \ | |
660 | - : \ | |
661 | - fastgetattr((tup), (attnum), (tupleDesc), (isnull)) \ | |
662 | - ) \ | |
663 | - : \ | |
664 | - heap_getsysattr((tup), (attnum), (tupleDesc), (isnull)) \ | |
665 | - ) | |
666 | - | |
667 | - | |
668 | -/* prototypes for functions in common/heaptuple.c */ | |
669 | -extern Size heap_compute_data_size(TupleDesc tupleDesc, | |
670 | - Datum *values, bool *isnull); | |
671 | -extern void heap_fill_tuple(TupleDesc tupleDesc, | |
672 | - Datum *values, bool *isnull, | |
673 | - char *data, Size data_size, | |
674 | - uint16 *infomask, bits8 *bit); | |
675 | -extern bool heap_attisnull(HeapTuple tup, int attnum); | |
676 | -extern Datum nocachegetattr(HeapTuple tup, int attnum, | |
677 | - TupleDesc att); | |
678 | -extern Datum heap_getsysattr(HeapTuple tup, int attnum, TupleDesc tupleDesc, | |
679 | - bool *isnull); | |
680 | -extern HeapTuple heap_copytuple(HeapTuple tuple); | |
681 | -extern void heap_copytuple_with_tuple(HeapTuple src, HeapTuple dest); | |
682 | -extern HeapTuple heap_form_tuple(TupleDesc tupleDescriptor, | |
683 | - Datum *values, bool *isnull); | |
684 | -extern HeapTuple heap_modify_tuple(HeapTuple tuple, | |
685 | - TupleDesc tupleDesc, | |
686 | - Datum *replValues, | |
687 | - bool *replIsnull, | |
688 | - bool *doReplace); | |
689 | -extern void heap_deform_tuple(HeapTuple tuple, TupleDesc tupleDesc, | |
690 | - Datum *values, bool *isnull); | |
691 | - | |
692 | -/* these three are deprecated versions of the three above: */ | |
693 | -extern HeapTuple heap_formtuple(TupleDesc tupleDescriptor, | |
694 | - Datum *values, char *nulls); | |
695 | -extern HeapTuple heap_modifytuple(HeapTuple tuple, | |
696 | - TupleDesc tupleDesc, | |
697 | - Datum *replValues, | |
698 | - char *replNulls, | |
699 | - char *replActions); | |
700 | -extern void heap_deformtuple(HeapTuple tuple, TupleDesc tupleDesc, | |
701 | - Datum *values, char *nulls); | |
702 | -extern void heap_freetuple(HeapTuple htup); | |
703 | -extern MinimalTuple heap_form_minimal_tuple(TupleDesc tupleDescriptor, | |
704 | - Datum *values, bool *isnull); | |
705 | -extern void heap_free_minimal_tuple(MinimalTuple mtup); | |
706 | -extern MinimalTuple heap_copy_minimal_tuple(MinimalTuple mtup); | |
707 | -extern HeapTuple heap_tuple_from_minimal_tuple(MinimalTuple mtup); | |
708 | -extern MinimalTuple minimal_tuple_from_heap_tuple(HeapTuple htup); | |
709 | - | |
710 | -#endif /* HTUP_DETAILS_H */ |
@@ -6,7 +6,7 @@ | ||
6 | 6 | * src/backend/optimizer/path/joinrels.c |
7 | 7 | * make_join_rel() |
8 | 8 | * |
9 | - * Portions Copyright (c) 2013, NIPPON TELEGRAPH AND TELEPHONE CORPORATION | |
9 | + * Portions Copyright (c) 2013-2014, NIPPON TELEGRAPH AND TELEPHONE CORPORATION | |
10 | 10 | * Portions Copyright (c) 1996-2012, PostgreSQL Global Development Group |
11 | 11 | * Portions Copyright (c) 1994, Regents of the University of California |
12 | 12 | * |
@@ -6,7 +6,7 @@ | ||
6 | 6 | * This header file is created from pg_stat_statements.c to implement |
7 | 7 | * normalization of query string. |
8 | 8 | * |
9 | - * Portions Copyright (c) 2008-2013, PostgreSQL Global Development Group | |
9 | + * Portions Copyright (c) 2008-2014, PostgreSQL Global Development Group | |
10 | 10 | */ |
11 | 11 | #ifndef NORMALIZE_QUERY_H |
12 | 12 | #define NORMALIZE_QUERY_H |
@@ -4,7 +4,7 @@ | ||
4 | 4 | * do instructions or hints to the planner using C-style block comments |
5 | 5 | * of the SQL. |
6 | 6 | * |
7 | - * Copyright (c) 2012-2013, NIPPON TELEGRAPH AND TELEPHONE CORPORATION | |
7 | + * Copyright (c) 2012-2014, NIPPON TELEGRAPH AND TELEPHONE CORPORATION | |
8 | 8 | * |
9 | 9 | *------------------------------------------------------------------------- |
10 | 10 | */ |
@@ -54,7 +54,7 @@ | ||
54 | 54 | #include "normalize_query.h" |
55 | 55 | |
56 | 56 | /* PostgreSQL 9.3 */ |
57 | -#include "htup_details.h" | |
57 | +#include "access/htup_details.h" | |
58 | 58 | |
59 | 59 | #ifdef PG_MODULE_MAGIC |
60 | 60 | PG_MODULE_MAGIC; |
@@ -34,7 +34,7 @@ | ||
34 | 34 | * disappear!) and also take the entry's mutex spinlock. |
35 | 35 | * |
36 | 36 | * |
37 | - * Copyright (c) 2008-2013, PostgreSQL Global Development Group | |
37 | + * Copyright (c) 2008-2014, PostgreSQL Global Development Group | |
38 | 38 | * |
39 | 39 | * IDENTIFICATION |
40 | 40 | * contrib/pg_stat_statements/pg_stat_statements.c |