Age Owner Branch data TLA Line data Source code
1 : : /*----------------------------------------------------------------------
2 : : *
3 : : * tableam.c
4 : : * Table access method routines too big to be inline functions.
5 : : *
6 : : * Portions Copyright (c) 1996-2026, PostgreSQL Global Development Group
7 : : * Portions Copyright (c) 1994, Regents of the University of California
8 : : *
9 : : *
10 : : * IDENTIFICATION
11 : : * src/backend/access/table/tableam.c
12 : : *
13 : : * NOTES
14 : : * Note that most functions in here are documented in tableam.h, rather than
15 : : * here. That's because there's a lot of inline functions in tableam.h and
16 : : * it'd be harder to understand if one constantly had to switch between files.
17 : : *
18 : : *----------------------------------------------------------------------
19 : : */
20 : : #include "postgres.h"
21 : :
22 : : #include <math.h>
23 : :
24 : : #include "access/syncscan.h"
25 : : #include "access/tableam.h"
26 : : #include "access/xact.h"
27 : : #include "optimizer/optimizer.h"
28 : : #include "optimizer/plancat.h"
29 : : #include "port/pg_bitutils.h"
30 : : #include "storage/bufmgr.h"
31 : : #include "storage/shmem.h"
32 : : #include "storage/smgr.h"
33 : :
34 : : /*
35 : : * Constants to control the behavior of block allocation to parallel workers
36 : : * during a parallel seqscan. Technically these values do not need to be
37 : : * powers of 2, but having them as powers of 2 makes the math more optimal
38 : : * and makes the ramp-down stepping more even.
39 : : */
40 : :
41 : : /* The number of I/O chunks we try to break a parallel seqscan down into */
42 : : #define PARALLEL_SEQSCAN_NCHUNKS 2048
43 : : /* Ramp down size of allocations when we've only this number of chunks left */
44 : : #define PARALLEL_SEQSCAN_RAMPDOWN_CHUNKS 64
45 : : /* Cap the size of parallel I/O chunks to this number of blocks */
46 : : #define PARALLEL_SEQSCAN_MAX_CHUNK_SIZE 8192
47 : :
48 : : /* GUC variables */
49 : : char *default_table_access_method = DEFAULT_TABLE_ACCESS_METHOD;
50 : : bool synchronize_seqscans = true;
51 : :
52 : :
53 : : /* ----------------------------------------------------------------------------
54 : : * Slot functions.
55 : : * ----------------------------------------------------------------------------
56 : : */
57 : :
58 : : const TupleTableSlotOps *
2796 andres@anarazel.de 59 :CBC 9994125 : table_slot_callbacks(Relation relation)
60 : : {
61 : : const TupleTableSlotOps *tts_cb;
62 : :
63 [ + + ]: 9994125 : if (relation->rd_tableam)
64 : 9989431 : tts_cb = relation->rd_tableam->slot_callbacks(relation);
65 [ + + ]: 4694 : else if (relation->rd_rel->relkind == RELKIND_FOREIGN_TABLE)
66 : : {
67 : : /*
68 : : * Historically FDWs expect to store heap tuples in slots. Continue
69 : : * handing them one, to make it less painful to adapt FDWs to new
70 : : * versions. The cost of a heap slot over a virtual slot is pretty
71 : : * small.
72 : : */
73 : 228 : tts_cb = &TTSOpsHeapTuple;
74 : : }
75 : : else
76 : : {
77 : : /*
78 : : * These need to be supported, as some parts of the code (like COPY)
79 : : * need to create slots for such relations too. It seems better to
80 : : * centralize the knowledge that a heap slot is the right thing in
81 : : * that case here.
82 : : */
83 [ + + - + ]: 4466 : Assert(relation->rd_rel->relkind == RELKIND_VIEW ||
84 : : relation->rd_rel->relkind == RELKIND_PARTITIONED_TABLE);
85 : 4466 : tts_cb = &TTSOpsVirtual;
86 : : }
87 : :
88 : 9994125 : return tts_cb;
89 : : }
90 : :
91 : : TupleTableSlot *
92 : 9698299 : table_slot_create(Relation relation, List **reglist)
93 : : {
94 : : const TupleTableSlotOps *tts_cb;
95 : : TupleTableSlot *slot;
96 : :
97 : 9698299 : tts_cb = table_slot_callbacks(relation);
98 : 9698299 : slot = MakeSingleTupleTableSlot(RelationGetDescr(relation), tts_cb);
99 : :
100 [ + + ]: 9698299 : if (reglist)
101 : 163157 : *reglist = lappend(*reglist, slot);
102 : :
103 : 9698299 : return slot;
104 : : }
105 : :
106 : :
107 : : /* ----------------------------------------------------------------------------
108 : : * Table scan functions.
109 : : * ----------------------------------------------------------------------------
110 : : */
111 : :
112 : : TableScanDesc
406 alvherre@kurilemu.de 113 : 41065 : table_beginscan_catalog(Relation relation, int nkeys, ScanKeyData *key)
114 : : {
2727 andres@anarazel.de 115 : 41065 : uint32 flags = SO_TYPE_SEQSCAN |
116 : : SO_ALLOW_STRAT | SO_ALLOW_SYNC | SO_ALLOW_PAGEMODE | SO_TEMP_SNAPSHOT;
2796 117 : 41065 : Oid relid = RelationGetRelid(relation);
118 : 41065 : Snapshot snapshot = RegisterSnapshot(GetCatalogSnapshot(relid));
119 : :
280 120 : 41065 : return table_beginscan_common(relation, snapshot, nkeys, key,
121 : : NULL, flags, SO_NONE);
122 : : }
123 : :
124 : :
125 : : /* ----------------------------------------------------------------------------
126 : : * Parallel table scan related functions.
127 : : * ----------------------------------------------------------------------------
128 : : */
129 : :
130 : : Size
2796 131 : 1325 : table_parallelscan_estimate(Relation rel, Snapshot snapshot)
132 : : {
133 : 1325 : Size sz = 0;
134 : :
135 [ + + ]: 1325 : if (IsMVCCSnapshot(snapshot))
136 : 1198 : sz = add_size(sz, EstimateSnapshotSpace(snapshot));
137 : : else
138 [ - + ]: 127 : Assert(snapshot == SnapshotAny);
139 : :
140 : 1325 : sz = add_size(sz, rel->rd_tableam->parallelscan_estimate(rel));
141 : :
142 : 1325 : return sz;
143 : : }
144 : :
145 : : void
146 : 1325 : table_parallelscan_initialize(Relation rel, ParallelTableScanDesc pscan,
147 : : Snapshot snapshot)
148 : : {
149 : 1325 : Size snapshot_off = rel->rd_tableam->parallelscan_initialize(rel, pscan);
150 : :
151 : 1325 : pscan->phs_snapshot_off = snapshot_off;
152 : :
153 [ + + ]: 1325 : if (IsMVCCSnapshot(snapshot))
154 : : {
155 : 1198 : SerializeSnapshot(snapshot, (char *) pscan + pscan->phs_snapshot_off);
156 : 1198 : pscan->phs_snapshot_any = false;
157 : : }
158 : : else
159 : : {
160 [ - + ]: 127 : Assert(snapshot == SnapshotAny);
161 : 127 : pscan->phs_snapshot_any = true;
162 : : }
163 : 1325 : }
164 : :
165 : : TableScanDesc
220 melanieplageman@gmai 166 : 4398 : table_beginscan_parallel(Relation relation, ParallelTableScanDesc pscan,
167 : : uint32 flags)
168 : : {
169 : : Snapshot snapshot;
170 : 4398 : uint32 internal_flags = SO_TYPE_SEQSCAN |
171 : : SO_ALLOW_STRAT | SO_ALLOW_SYNC | SO_ALLOW_PAGEMODE;
172 : :
776 tgl@sss.pgh.pa.us 173 [ + - + - : 4398 : Assert(RelFileLocatorEquals(relation->rd_locator, pscan->phs_locator));
- + ]
174 : :
1508 pg@bowt.ie 175 [ + + ]: 4398 : if (!pscan->phs_snapshot_any)
176 : : {
177 : : /* Snapshot was serialized -- restore it */
178 : 4127 : snapshot = RestoreSnapshot((char *) pscan + pscan->phs_snapshot_off);
2796 andres@anarazel.de 179 : 4127 : RegisterSnapshot(snapshot);
220 melanieplageman@gmai 180 : 4127 : internal_flags |= SO_TEMP_SNAPSHOT;
181 : : }
182 : : else
183 : : {
184 : : /* SnapshotAny passed by caller (not serialized) */
2796 andres@anarazel.de 185 : 271 : snapshot = SnapshotAny;
186 : : }
187 : :
280 188 : 4398 : return table_beginscan_common(relation, snapshot, 0, NULL,
189 : : pscan, internal_flags, flags);
190 : : }
191 : :
192 : : TableScanDesc
343 drowley@postgresql.o 193 : 132 : table_beginscan_parallel_tidrange(Relation relation,
194 : : ParallelTableScanDesc pscan,
195 : : uint32 flags)
196 : : {
197 : : Snapshot snapshot;
198 : : TableScanDesc sscan;
220 melanieplageman@gmai 199 : 132 : uint32 internal_flags = SO_TYPE_TIDRANGESCAN | SO_ALLOW_PAGEMODE;
200 : :
343 drowley@postgresql.o 201 [ + - + - : 132 : Assert(RelFileLocatorEquals(relation->rd_locator, pscan->phs_locator));
- + ]
202 : :
203 : : /* disable syncscan in parallel tid range scan. */
204 : 132 : pscan->phs_syncscan = false;
205 : :
206 [ + - ]: 132 : if (!pscan->phs_snapshot_any)
207 : : {
208 : : /* Snapshot was serialized -- restore it */
209 : 132 : snapshot = RestoreSnapshot((char *) pscan + pscan->phs_snapshot_off);
210 : 132 : RegisterSnapshot(snapshot);
220 melanieplageman@gmai 211 : 132 : internal_flags |= SO_TEMP_SNAPSHOT;
212 : : }
213 : : else
214 : : {
215 : : /* SnapshotAny passed by caller (not serialized) */
343 drowley@postgresql.o 216 :UBC 0 : snapshot = SnapshotAny;
217 : : }
218 : :
280 andres@anarazel.de 219 :CBC 132 : sscan = table_beginscan_common(relation, snapshot, 0, NULL,
220 : : pscan, internal_flags, flags);
343 drowley@postgresql.o 221 : 132 : return sscan;
222 : : }
223 : :
224 : :
225 : : /* ------------------------------------------------------------------------
226 : : * Functions for non-modifying operations on individual tuples
227 : : * ------------------------------------------------------------------------
228 : : */
229 : :
230 : : void
2723 andres@anarazel.de 231 : 215 : table_tuple_get_latest_tid(TableScanDesc scan, ItemPointer tid)
232 : : {
2724 tgl@sss.pgh.pa.us 233 : 215 : Relation rel = scan->rs_rd;
2729 andres@anarazel.de 234 : 215 : const TableAmRoutine *tableam = rel->rd_tableam;
235 : :
236 : : /*
237 : : * Since this can be called with user-supplied TID, don't trust the input
238 : : * too much.
239 : : */
240 [ + + ]: 215 : if (!tableam->tuple_tid_valid(scan, tid))
241 [ + - ]: 8 : ereport(ERROR,
242 : : (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
243 : : errmsg("tid (%u, %u) is not valid for relation \"%s\"",
244 : : ItemPointerGetBlockNumberNoCheck(tid),
245 : : ItemPointerGetOffsetNumberNoCheck(tid),
246 : : RelationGetRelationName(rel))));
247 : :
2728 tgl@sss.pgh.pa.us 248 : 207 : tableam->tuple_get_latest_tid(scan, tid);
2729 andres@anarazel.de 249 : 207 : }
250 : :
251 : :
252 : : /* ----------------------------------------------------------------------------
253 : : * Functions to make modifications a bit simpler.
254 : : * ----------------------------------------------------------------------------
255 : : */
256 : :
257 : : /*
258 : : * simple_table_tuple_insert - insert a tuple
259 : : *
260 : : * Currently, this routine differs from table_tuple_insert only in supplying a
261 : : * default command ID and not allowing access to the speedup options.
262 : : */
263 : : void
938 akorotkov@postgresql 264 : 96194 : simple_table_tuple_insert(Relation rel, TupleTableSlot *slot)
265 : : {
266 : 96194 : table_tuple_insert(rel, slot, GetCurrentCommandId(true), 0, NULL);
2784 andres@anarazel.de 267 : 96194 : }
268 : :
269 : : /*
270 : : * simple_table_tuple_delete - delete a tuple
271 : : *
272 : : * This routine may be used to delete a tuple when concurrent updates of
273 : : * the target tuple are not expected (for example, because we have a lock
274 : : * on the relation associated with the tuple). Any failure is reported
275 : : * via ereport().
276 : : */
277 : : void
938 akorotkov@postgresql 278 : 40314 : simple_table_tuple_delete(Relation rel, ItemPointer tid, Snapshot snapshot)
279 : : {
280 : : TM_Result result;
281 : : TM_FailureData tmfd;
282 : :
2723 andres@anarazel.de 283 : 40314 : result = table_tuple_delete(rel, tid,
284 : : GetCurrentCommandId(true),
285 : : 0, snapshot, InvalidSnapshot,
286 : : true /* wait for commit */ ,
287 : : &tmfd);
288 : :
2784 289 [ - + - - : 40314 : switch (result)
- ]
290 : : {
2784 andres@anarazel.de 291 :UBC 0 : case TM_SelfModified:
292 : : /* Tuple was already updated in current command? */
293 [ # # ]: 0 : elog(ERROR, "tuple already updated by self");
294 : : break;
295 : :
2784 andres@anarazel.de 296 :CBC 40314 : case TM_Ok:
297 : : /* done successfully */
298 : 40314 : break;
299 : :
2784 andres@anarazel.de 300 :UBC 0 : case TM_Updated:
301 [ # # ]: 0 : elog(ERROR, "tuple concurrently updated");
302 : : break;
303 : :
304 : 0 : case TM_Deleted:
305 [ # # ]: 0 : elog(ERROR, "tuple concurrently deleted");
306 : : break;
307 : :
308 : 0 : default:
2723 309 [ # # ]: 0 : elog(ERROR, "unrecognized table_tuple_delete status: %u", result);
310 : : break;
311 : : }
2784 andres@anarazel.de 312 :CBC 40314 : }
313 : :
314 : : /*
315 : : * simple_table_tuple_update - replace a tuple
316 : : *
317 : : * This routine may be used to update a tuple when concurrent updates of
318 : : * the target tuple are not expected (for example, because we have a lock
319 : : * on the relation associated with the tuple). Any failure is reported
320 : : * via ereport().
321 : : */
322 : : void
2723 323 : 31926 : simple_table_tuple_update(Relation rel, ItemPointer otid,
324 : : TupleTableSlot *slot,
325 : : Snapshot snapshot,
326 : : TU_UpdateIndexes *update_indexes)
327 : : {
328 : : TM_Result result;
329 : : TM_FailureData tmfd;
330 : : LockTupleMode lockmode;
331 : :
332 : 31926 : result = table_tuple_update(rel, otid, slot,
333 : : GetCurrentCommandId(true),
334 : : 0, snapshot, InvalidSnapshot,
335 : : true /* wait for commit */ ,
336 : : &tmfd, &lockmode, update_indexes);
337 : :
2784 338 [ - + - - : 31926 : switch (result)
- ]
339 : : {
2784 andres@anarazel.de 340 :UBC 0 : case TM_SelfModified:
341 : : /* Tuple was already updated in current command? */
342 [ # # ]: 0 : elog(ERROR, "tuple already updated by self");
343 : : break;
344 : :
2784 andres@anarazel.de 345 :CBC 31926 : case TM_Ok:
346 : : /* done successfully */
347 : 31926 : break;
348 : :
2784 andres@anarazel.de 349 :UBC 0 : case TM_Updated:
350 [ # # ]: 0 : elog(ERROR, "tuple concurrently updated");
351 : : break;
352 : :
353 : 0 : case TM_Deleted:
354 [ # # ]: 0 : elog(ERROR, "tuple concurrently deleted");
355 : : break;
356 : :
357 : 0 : default:
2723 358 [ # # ]: 0 : elog(ERROR, "unrecognized table_tuple_update status: %u", result);
359 : : break;
360 : : }
2784 andres@anarazel.de 361 :CBC 31926 : }
362 : :
363 : :
364 : : /* ----------------------------------------------------------------------------
365 : : * Helper functions to implement parallel scans for block oriented AMs.
366 : : * ----------------------------------------------------------------------------
367 : : */
368 : :
369 : : Size
2796 370 : 1325 : table_block_parallelscan_estimate(Relation rel)
371 : : {
372 : 1325 : return sizeof(ParallelBlockTableScanDescData);
373 : : }
374 : :
375 : : Size
376 : 1325 : table_block_parallelscan_initialize(Relation rel, ParallelTableScanDesc pscan)
377 : : {
378 : 1325 : ParallelBlockTableScanDesc bpscan = (ParallelBlockTableScanDesc) pscan;
379 : :
776 tgl@sss.pgh.pa.us 380 : 1325 : bpscan->base.phs_locator = rel->rd_locator;
2796 andres@anarazel.de 381 : 1325 : bpscan->phs_nblocks = RelationGetNumberOfBlocks(rel);
382 : : /* compare phs_syncscan initialization to similar logic in initscan */
383 : 3648 : bpscan->base.phs_syncscan = synchronize_seqscans &&
384 [ + + + - ]: 2323 : !RelationUsesLocalBuffers(rel) &&
385 [ + + ]: 998 : bpscan->phs_nblocks > NBuffers / 4;
62 nathan@postgresql.or 386 :GNC 1325 : pg_atomic_init_u32(&bpscan->phs_startblock, InvalidBlockNumber);
387 : 1325 : pg_atomic_init_u32(&bpscan->phs_numblock, InvalidBlockNumber);
2796 andres@anarazel.de 388 :CBC 1325 : pg_atomic_init_u64(&bpscan->phs_nallocated, 0);
389 : :
390 : 1325 : return sizeof(ParallelBlockTableScanDescData);
391 : : }
392 : :
393 : : void
394 : 160 : table_block_parallelscan_reinitialize(Relation rel, ParallelTableScanDesc pscan)
395 : : {
396 : 160 : ParallelBlockTableScanDesc bpscan = (ParallelBlockTableScanDesc) pscan;
397 : :
398 : : /*
399 : : * Reset the start block and block limit too. These are set by the first
400 : : * participant to call table_block_parallelscan_startblock_init(), and a
401 : : * rescan may want to scan a different range of blocks, e.g. a TID Range
402 : : * Scan with different TID bounds.
403 : : */
20 drowley@postgresql.o 404 :GNC 160 : pg_atomic_write_u32(&bpscan->phs_startblock, InvalidBlockNumber);
405 : 160 : pg_atomic_write_u32(&bpscan->phs_numblock, InvalidBlockNumber);
2796 andres@anarazel.de 406 :CBC 160 : pg_atomic_write_u64(&bpscan->phs_nallocated, 0);
407 : 160 : }
408 : :
409 : : /*
410 : : * find and set the scan's startblock
411 : : *
412 : : * Determine where the parallel seq scan should start. This function may be
413 : : * called many times, once by each parallel worker. We must be careful only
414 : : * to set the phs_startblock and phs_numblock fields once.
415 : : *
416 : : * Callers may optionally specify a non-InvalidBlockNumber value for
417 : : * 'startblock' to force the scan to start at the given page. Likewise,
418 : : * 'numblocks' can be specified as a non-InvalidBlockNumber to limit the
419 : : * number of blocks to scan to that many blocks.
420 : : */
421 : : void
2293 drowley@postgresql.o 422 : 2895 : table_block_parallelscan_startblock_init(Relation rel,
423 : : ParallelBlockTableScanWorker pbscanwork,
424 : : ParallelBlockTableScanDesc pbscan,
425 : : BlockNumber startblock,
426 : : BlockNumber numblocks)
427 : : {
428 : : StaticAssertDecl(MaxBlockNumber <= 0xFFFFFFFE,
429 : : "pg_nextpower2_32 may be too small for non-standard BlockNumber width");
430 : :
431 : : BlockNumber scan_nblocks;
432 : :
433 : : /* Reset the state we use for controlling allocation size. */
434 : 2895 : memset(pbscanwork, 0, sizeof(*pbscanwork));
435 : :
436 : : /*
437 : : * When the caller specified a limit on the number of blocks to scan, set
438 : : * that in the ParallelBlockTableScanDesc, if it's not been done by
439 : : * another worker already.
440 : : */
62 nathan@postgresql.or 441 [ + + ]:GNC 2895 : if (numblocks != InvalidBlockNumber)
442 : : {
443 : 140 : uint32 expected = InvalidBlockNumber;
444 : :
445 : 140 : pg_atomic_compare_exchange_u32(&pbscan->phs_numblock, &expected,
446 : : numblocks);
447 : : }
448 : :
449 : : /*
450 : : * If the scan's phs_startblock has not yet been initialized, we must do
451 : : * so now. If a startblock was specified, start there, otherwise if this
452 : : * is not a synchronized scan, we just start at block 0, but if it is a
453 : : * synchronized scan, we must get the starting position from the
454 : : * synchronized scan machinery.
455 : : *
456 : : * If another worker initializes phs_startblock concurrently, just use
457 : : * their value.
458 : : */
459 [ + + ]: 2895 : if (pg_atomic_read_u32(&pbscan->phs_startblock) == InvalidBlockNumber)
460 : : {
461 : : BlockNumber newstartblock;
462 : 1472 : uint32 expected = InvalidBlockNumber;
463 : :
343 drowley@postgresql.o 464 [ + + ]:CBC 1472 : if (startblock != InvalidBlockNumber)
62 nathan@postgresql.or 465 :GNC 28 : newstartblock = startblock;
343 drowley@postgresql.o 466 [ + + ]:CBC 1444 : else if (!pbscan->base.phs_syncscan)
62 nathan@postgresql.or 467 :GNC 1442 : newstartblock = 0;
468 : : else
469 : 2 : newstartblock = ss_get_location(rel, pbscan->phs_nblocks);
470 : :
471 : 1472 : pg_atomic_compare_exchange_u32(&pbscan->phs_startblock, &expected,
472 : : newstartblock);
473 : : }
474 : :
475 : : /*
476 : : * Figure out how many blocks we're going to scan; either all of them, or
477 : : * just phs_numblock's worth, if a limit has been imposed.
478 : : */
479 [ + + ]: 2895 : if (pg_atomic_read_u32(&pbscan->phs_numblock) == InvalidBlockNumber)
343 drowley@postgresql.o 480 :CBC 2755 : scan_nblocks = pbscan->phs_nblocks;
481 : : else
62 nathan@postgresql.or 482 :GNC 140 : scan_nblocks = pg_atomic_read_u32(&pbscan->phs_numblock);
483 : :
484 : : /*
485 : : * We determine the chunk size based on scan_nblocks. First we split
486 : : * scan_nblocks into PARALLEL_SEQSCAN_NCHUNKS chunks then we calculate the
487 : : * next highest power of 2 number of the result. This means we split the
488 : : * blocks we're scanning into somewhere between PARALLEL_SEQSCAN_NCHUNKS
489 : : * and PARALLEL_SEQSCAN_NCHUNKS / 2 chunks.
490 : : */
343 drowley@postgresql.o 491 [ + + ]:CBC 2895 : pbscanwork->phsw_chunk_size = pg_nextpower2_32(Max(scan_nblocks /
492 : : PARALLEL_SEQSCAN_NCHUNKS, 1));
493 : :
494 : : /*
495 : : * Ensure we don't go over the maximum chunk size with larger tables. This
496 : : * means we may get much more than PARALLEL_SEQSCAN_NCHUNKS for larger
497 : : * tables. Too large a chunk size has been shown to be detrimental to
498 : : * sequential scan performance.
499 : : */
500 : 2895 : pbscanwork->phsw_chunk_size = Min(pbscanwork->phsw_chunk_size,
501 : : PARALLEL_SEQSCAN_MAX_CHUNK_SIZE);
2796 andres@anarazel.de 502 : 2895 : }
503 : :
504 : : /*
505 : : * get the next page to scan
506 : : *
507 : : * Get the next page to scan. Even if there are no pages left to scan,
508 : : * another backend could have grabbed a page to scan and not yet finished
509 : : * looking at it, so it doesn't follow that the scan is done when the first
510 : : * backend gets an InvalidBlockNumber return.
511 : : */
512 : : BlockNumber
2293 drowley@postgresql.o 513 : 146676 : table_block_parallelscan_nextpage(Relation rel,
514 : : ParallelBlockTableScanWorker pbscanwork,
515 : : ParallelBlockTableScanDesc pbscan)
516 : : {
517 : : BlockNumber scan_nblocks;
518 : : BlockNumber page;
519 : : uint64 nallocated;
520 : :
521 : : /*
522 : : * The logic below allocates block numbers out to parallel workers in a
523 : : * way that each worker will receive a set of consecutive block numbers to
524 : : * scan. Earlier versions of this would allocate the next highest block
525 : : * number to the next worker to call this function. This would generally
526 : : * result in workers never receiving consecutive block numbers. Some
527 : : * operating systems would not detect the sequential I/O pattern due to
528 : : * each backend being a different process which could result in poor
529 : : * performance due to inefficient or no readahead. To work around this
530 : : * issue, we now allocate a range of block numbers for each worker and
531 : : * when they come back for another block, we give them the next one in
532 : : * that range until the range is complete. When the worker completes the
533 : : * range of blocks we then allocate another range for it and return the
534 : : * first block number from that range.
535 : : *
536 : : * Here we name these ranges of blocks "chunks". The initial size of
537 : : * these chunks is determined in table_block_parallelscan_startblock_init
538 : : * based on the number of blocks to scan. Towards the end of the scan, we
539 : : * start making reductions in the size of the chunks in order to attempt
540 : : * to divide the remaining work over all the workers as evenly as
541 : : * possible.
542 : : *
543 : : * Here pbscanwork is local worker memory. phsw_chunk_remaining tracks
544 : : * the number of blocks remaining in the chunk. When that reaches 0 then
545 : : * we must allocate a new chunk for the worker.
546 : : *
547 : : * phs_nallocated tracks how many blocks have been allocated to workers
548 : : * already. When phs_nallocated >= rs_nblocks, all blocks have been
549 : : * allocated.
550 : : *
551 : : * Because we use an atomic fetch-and-add to fetch the current value, the
552 : : * phs_nallocated counter will exceed rs_nblocks, because workers will
553 : : * still increment the value, when they try to allocate the next block but
554 : : * all blocks have been allocated already. The counter must be 64 bits
555 : : * wide because of that, to avoid wrapping around when scan_nblocks is
556 : : * close to 2^32.
557 : : *
558 : : * The actual block to return is calculated by adding the counter to the
559 : : * starting block number, modulo phs_nblocks.
560 : : */
561 : :
562 : : /* First, figure out how many blocks we're planning on scanning */
62 nathan@postgresql.or 563 [ + + ]:GNC 146676 : if (pg_atomic_read_u32(&pbscan->phs_numblock) == InvalidBlockNumber)
343 drowley@postgresql.o 564 :CBC 145884 : scan_nblocks = pbscan->phs_nblocks;
565 : : else
62 nathan@postgresql.or 566 :GNC 792 : scan_nblocks = pg_atomic_read_u32(&pbscan->phs_numblock);
567 : :
568 : : /*
569 : : * Now check if we have any remaining blocks in a previous chunk for this
570 : : * worker. We must consume all of the blocks from that before we allocate
571 : : * a new chunk to the worker.
572 : : */
2293 drowley@postgresql.o 573 [ + + ]:CBC 146676 : if (pbscanwork->phsw_chunk_remaining > 0)
574 : : {
575 : : /*
576 : : * Give them the next block in the range and update the remaining
577 : : * number of blocks.
578 : : */
579 : 17946 : nallocated = ++pbscanwork->phsw_nallocated;
580 : 17946 : pbscanwork->phsw_chunk_remaining--;
581 : : }
582 : : else
583 : : {
584 : : /*
585 : : * When we've only got PARALLEL_SEQSCAN_RAMPDOWN_CHUNKS chunks
586 : : * remaining in the scan, we half the chunk size. Since we reduce the
587 : : * chunk size here, we'll hit this again after doing
588 : : * PARALLEL_SEQSCAN_RAMPDOWN_CHUNKS at the new size. After a few
589 : : * iterations of this, we'll end up doing the last few blocks with the
590 : : * chunk size set to 1.
591 : : */
592 [ + + ]: 128730 : if (pbscanwork->phsw_chunk_size > 1 &&
343 593 : 3939 : pbscanwork->phsw_nallocated > scan_nblocks -
2293 594 [ + + ]: 3939 : (pbscanwork->phsw_chunk_size * PARALLEL_SEQSCAN_RAMPDOWN_CHUNKS))
595 : 13 : pbscanwork->phsw_chunk_size >>= 1;
596 : :
597 : 128730 : nallocated = pbscanwork->phsw_nallocated =
598 : 128730 : pg_atomic_fetch_add_u64(&pbscan->phs_nallocated,
599 : 128730 : pbscanwork->phsw_chunk_size);
600 : :
601 : : /*
602 : : * Set the remaining number of blocks in this chunk so that subsequent
603 : : * calls from this worker continue on with this chunk until it's done.
604 : : */
605 : 128730 : pbscanwork->phsw_chunk_remaining = pbscanwork->phsw_chunk_size - 1;
606 : : }
607 : :
608 : : /* Check if we've run out of blocks to scan */
343 609 [ + + ]: 146676 : if (nallocated >= scan_nblocks)
2796 andres@anarazel.de 610 : 2895 : page = InvalidBlockNumber; /* all blocks have been allocated */
611 : : else
62 nathan@postgresql.or 612 :GNC 143781 : page = (nallocated + pg_atomic_read_u32(&pbscan->phs_startblock)) % pbscan->phs_nblocks;
613 : :
614 : : /*
615 : : * Report scan location. Normally, we report the current page number.
616 : : * When we reach the end of the scan, though, we report the starting page,
617 : : * not the ending page, just so the starting positions for later scans
618 : : * doesn't slew backwards. We only report the position at the end of the
619 : : * scan once, though: subsequent callers will report nothing.
620 : : */
2796 andres@anarazel.de 621 [ + + ]:CBC 146676 : if (pbscan->base.phs_syncscan)
622 : : {
623 [ + + ]: 22130 : if (page != InvalidBlockNumber)
624 : 22125 : ss_report_location(rel, page);
625 [ + + ]: 5 : else if (nallocated == pbscan->phs_nblocks)
62 nathan@postgresql.or 626 :GNC 2 : ss_report_location(rel, pg_atomic_read_u32(&pbscan->phs_startblock));
627 : : }
628 : :
2796 andres@anarazel.de 629 :CBC 146676 : return page;
630 : : }
631 : :
632 : : /* ----------------------------------------------------------------------------
633 : : * Helper functions to implement relation sizing for block oriented AMs.
634 : : * ----------------------------------------------------------------------------
635 : : */
636 : :
637 : : /*
638 : : * table_block_relation_size
639 : : *
640 : : * If a table AM uses the various relation forks as the sole place where data
641 : : * is stored, and if it uses them in the expected manner (e.g. the actual data
642 : : * is in the main fork rather than some other), it can use this implementation
643 : : * of the relation_size callback rather than implementing its own.
644 : : */
645 : : uint64
2677 rhaas@postgresql.org 646 : 1595221 : table_block_relation_size(Relation rel, ForkNumber forkNumber)
647 : : {
648 : 1595221 : uint64 nblocks = 0;
649 : :
650 : : /* InvalidForkNumber indicates returning the size for all forks */
651 [ - + ]: 1595221 : if (forkNumber == InvalidForkNumber)
652 : : {
2677 rhaas@postgresql.org 653 [ # # ]:UBC 0 : for (int i = 0; i < MAX_FORKNUM; i++)
1942 tgl@sss.pgh.pa.us 654 : 0 : nblocks += smgrnblocks(RelationGetSmgr(rel), i);
655 : : }
656 : : else
1942 tgl@sss.pgh.pa.us 657 :CBC 1595221 : nblocks = smgrnblocks(RelationGetSmgr(rel), forkNumber);
658 : :
2677 rhaas@postgresql.org 659 : 1595202 : return nblocks * BLCKSZ;
660 : : }
661 : :
662 : : /*
663 : : * table_block_relation_estimate_size
664 : : *
665 : : * This function can't be directly used as the implementation of the
666 : : * relation_estimate_size callback, because it has a few additional parameters.
667 : : * Instead, it is intended to be used as a helper function; the caller can
668 : : * pass through the arguments to its relation_estimate_size function plus the
669 : : * additional values required here.
670 : : *
671 : : * overhead_bytes_per_tuple should contain the approximate number of bytes
672 : : * of storage required to store a tuple above and beyond what is required for
673 : : * the tuple data proper. Typically, this would include things like the
674 : : * size of the tuple header and item pointer. This is only used for query
675 : : * planning, so a table AM where the value is not constant could choose to
676 : : * pass a "best guess".
677 : : *
678 : : * usable_bytes_per_page should contain the approximate number of bytes per
679 : : * page usable for tuple data, excluding the page header and any anticipated
680 : : * special space.
681 : : */
682 : : void
683 : 356868 : table_block_relation_estimate_size(Relation rel, int32 *attr_widths,
684 : : BlockNumber *pages, double *tuples,
685 : : double *allvisfrac,
686 : : Size overhead_bytes_per_tuple,
687 : : Size usable_bytes_per_page)
688 : : {
689 : : BlockNumber curpages;
690 : : BlockNumber relpages;
691 : : double reltuples;
692 : : BlockNumber relallvisible;
693 : : double density;
694 : :
695 : : /* it should have storage, so we can call the smgr */
696 : 356868 : curpages = RelationGetNumberOfBlocks(rel);
697 : :
698 : : /* coerce values in pg_class to more desirable types */
699 : 356868 : relpages = (BlockNumber) rel->rd_rel->relpages;
700 : 356868 : reltuples = (double) rel->rd_rel->reltuples;
701 : 356868 : relallvisible = (BlockNumber) rel->rd_rel->relallvisible;
702 : :
703 : : /*
704 : : * HACK: if the relation has never yet been vacuumed, use a minimum size
705 : : * estimate of 10 pages. The idea here is to avoid assuming a
706 : : * newly-created table is really small, even if it currently is, because
707 : : * that may not be true once some data gets loaded into it. Once a vacuum
708 : : * or analyze cycle has been done on it, it's more reasonable to believe
709 : : * the size is somewhat stable.
710 : : *
711 : : * (Note that this is only an issue if the plan gets cached and used again
712 : : * after the table has been filled. What we're trying to avoid is using a
713 : : * nestloop-type plan on a table that has grown substantially since the
714 : : * plan was made. Normally, autovacuum/autoanalyze will occur once enough
715 : : * inserts have happened and cause cached-plan invalidation; but that
716 : : * doesn't happen instantaneously, and it won't happen at all for cases
717 : : * such as temporary tables.)
718 : : *
719 : : * We test "never vacuumed" by seeing whether reltuples < 0.
720 : : *
721 : : * If the table has inheritance children, we don't apply this heuristic.
722 : : * Totally empty parent tables are quite common, so we should be willing
723 : : * to believe that they are empty.
724 : : */
725 [ + + + + ]: 356868 : if (curpages < 10 &&
2258 tgl@sss.pgh.pa.us 726 : 86721 : reltuples < 0 &&
2677 rhaas@postgresql.org 727 [ + + ]: 86721 : !rel->rd_rel->relhassubclass)
728 : 84603 : curpages = 10;
729 : :
730 : : /* report estimated # pages */
731 : 356868 : *pages = curpages;
732 : : /* quick exit if rel is clearly empty */
733 [ + + ]: 356868 : if (curpages == 0)
734 : : {
735 : 17271 : *tuples = 0;
736 : 17271 : *allvisfrac = 0;
737 : 17271 : return;
738 : : }
739 : :
740 : : /* estimate number of tuples from previous tuple density */
2258 tgl@sss.pgh.pa.us 741 [ + + + + ]: 339597 : if (reltuples >= 0 && relpages > 0)
2677 rhaas@postgresql.org 742 : 219151 : density = reltuples / (double) relpages;
743 : : else
744 : : {
745 : : /*
746 : : * When we have no data because the relation was never yet vacuumed,
747 : : * estimate tuple width from attribute datatypes. We assume here that
748 : : * the pages are completely full, which is OK for tables but is
749 : : * probably an overestimate for indexes. Fortunately
750 : : * get_relation_info() can clamp the overestimate to the parent
751 : : * table's size.
752 : : *
753 : : * Note: this code intentionally disregards alignment considerations,
754 : : * because (a) that would be gilding the lily considering how crude
755 : : * the estimate is, (b) it creates platform dependencies in the
756 : : * default plans which are kind of a headache for regression testing,
757 : : * and (c) different table AMs might use different padding schemes.
758 : : */
759 : : int32 tuple_width;
760 : : int fillfactor;
761 : :
762 : : /*
763 : : * Without reltuples/relpages, we also need to consider fillfactor.
764 : : * The other branch considers it implicitly by calculating density
765 : : * from actual relpages/reltuples statistics.
766 : : */
938 akorotkov@postgresql 767 [ + + ]: 120446 : fillfactor = RelationGetFillFactor(rel, HEAP_DEFAULT_FILLFACTOR);
768 : :
2677 rhaas@postgresql.org 769 : 120446 : tuple_width = get_rel_data_width(rel, attr_widths);
770 : 120446 : tuple_width += overhead_bytes_per_tuple;
771 : : /* note: integer division is intentional here */
1221 tomas.vondra@postgre 772 : 120446 : density = (usable_bytes_per_page * fillfactor / 100) / tuple_width;
773 : : /* There's at least one row on the page, even with low fillfactor. */
624 774 : 120446 : density = clamp_row_est(density);
775 : : }
2677 rhaas@postgresql.org 776 : 339597 : *tuples = rint(density * (double) curpages);
777 : :
778 : : /*
779 : : * We use relallvisible as-is, rather than scaling it up like we do for
780 : : * the pages and tuples counts, on the theory that any pages added since
781 : : * the last VACUUM are most likely not marked all-visible. But costsize.c
782 : : * wants it converted to a fraction.
783 : : */
784 [ + + - + ]: 339597 : if (relallvisible == 0 || curpages <= 0)
785 : 170992 : *allvisfrac = 0;
786 [ + + ]: 168605 : else if ((double) relallvisible >= curpages)
787 : 96207 : *allvisfrac = 1;
788 : : else
789 : 72398 : *allvisfrac = (double) relallvisible / curpages;
790 : : }
|
