1/*-------------------------------------------------------------------------
4 * Sort tuples for insertion into a new hash index.
6 * When building a very large hash index, we pre-sort the tuples by bucket
7 * number to improve locality of access to the index, and thereby avoid
8 * thrashing. We use tuplesort.c to sort the given index tuples into order.
10 * Note: if the number of rows in the table has been underestimated,
11 * bucket splits may occur during the index build. In that case we'd
12 * be inserting into two or more buckets for each possible masked-off
13 * hash code value. That's no big problem though, since we'll still have
14 * plenty of locality of access.
17 * Portions Copyright (c) 1996-2025, PostgreSQL Global Development Group
18 * Portions Copyright (c) 1994, Regents of the University of California
21 * src/backend/access/hash/hashsort.c
23 *-------------------------------------------------------------------------
37 * Status record for spooling/sorting phase.
45 * We sort the hash keys based on the buckets they belong to, then by the
46 * hash values themselves, to optimize insertions onto hash pages. The
47 * masks below are used in _hash_hashkey2bucket to determine the bucket of
57 * create and initialize a spool structure
67 * Determine the bitmask for hash code values. Since there are currently
68 * num_buckets buckets in the index, the appropriate mask can be computed
71 * NOTE : This hash mask calculation should be in sync with similar
72 * calculation in _hash_init_metabuffer.
79 * We size the sort area as maintenance_work_mem rather than work_mem to
80 * speed index creation. This should be OK since a single backend can't
81 * run multiple index creations in parallel.
96 * clean up a spool structure and its substructures.
106 * spool an index entry into the sort file.
116 * given a spool loaded by successive calls to _h_spool,
117 * create an entire index.
124#ifdef USE_ASSERT_CHECKING
133 * Technically, it isn't critical that hash keys be found in sorted
134 * order, since this sorting is only used to increase locality of
135 * access as a performance optimization. It still seems like a good
136 * idea to test tuplesort.c's handling of hash index tuple sorts
137 * through an assertion, though.
139#ifdef USE_ASSERT_CHECKING
140 uint32 lasthashkey = hashkey;
145 Assert(hashkey >= lasthashkey);
148 /* the tuples are sorted by hashkey, so pass 'sorted' as true */
151 /* allow insertion phase to be interrupted, and track progress */
void pgstat_progress_update_param(int index, int64 val)
static Datum values[MAXATTR]
Assert(PointerIsAligned(start, uint64))
void _hash_doinsert(Relation rel, IndexTuple itup, Relation heapRel, bool sorted)
void _h_spool(HSpool *hspool, ItemPointer self, const Datum *values, const bool *isnull)
void _h_indexbuild(HSpool *hspool, Relation heapRel)
HSpool * _h_spoolinit(Relation heap, Relation index, uint32 num_buckets)
void _h_spooldestroy(HSpool *hspool)
uint32 _hash_get_indextuple_hashkey(IndexTuple itup)
Bucket _hash_hashkey2bucket(uint32 hashkey, uint32 maxbucket, uint32 highmask, uint32 lowmask)
void pfree(void *pointer)
void * palloc0(Size size)
#define CHECK_FOR_INTERRUPTS()
static uint32 pg_nextpower2_32(uint32 num)
#define PROGRESS_CREATEIDX_TUPLES_DONE
Tuplesortstate * sortstate
void tuplesort_performsort(Tuplesortstate *state)
void tuplesort_end(Tuplesortstate *state)
IndexTuple tuplesort_getindextuple(Tuplesortstate *state, bool forward)
void tuplesort_putindextuplevalues(Tuplesortstate *state, Relation rel, ItemPointer self, const Datum *values, const bool *isnull)
Tuplesortstate * tuplesort_begin_index_hash(Relation heapRel, Relation indexRel, uint32 high_mask, uint32 low_mask, uint32 max_buckets, int workMem, SortCoordinate coordinate, int sortopt)