Accelerating the construction and detection of hash tables using symmetric vector processing

Abstract

The present invention relates to hash join acceleration. In an embodiment, a computer receives a request to join a constructed data row with a probe data row. Each data row is associated with a corresponding join key value. From a plurality of buckets in a hash table, a bucket containing entries of a plurality of corresponding join key values ​​in corresponding positions in the bucket is selected. It is detected whether the bucket contains entries of the join key values ​​of the constructed data row. When constructing, multiple positions in the bucket are checked concurrently to find empty positions to store entries of the join key values ​​of the constructed data row. Buckets are probed concurrently to detect whether entries in the bucket include entries of the join key values ​​of the probe data row. For a join request, a response based on concurrent probes of the bucket is sent.

Description

Technical Field

[0001] The present invention relates to accelerating relational joins, and is an optimization technique and a hash table for joining row sets. Background Art

[0002] Join query is common in relational database management system (RDBMS).Join query combines rows from two or more database tables based on the set of related join key columns.Herein, join key can be a column that participates in the predicate of relational join such as equijoin, such as a column in a relational table or a column family.Join key can be or may not be a candidate key of a database table or any other database table or a part of a composite candidate key that contains the column.Candidate key is a primary key, a secondary key or any other key that uniquely identifies a row.Can be by processing the column of one of the database tables (referred to as build table in this article) into a data structure during the construction phase, and then using the join key column of the remaining database table (referred to as the detection table in this article) in the detection phase to detect the matching item of the data structure to perform the connection of two database tables.For example, hash join fills a hash table during the construction phase by applying a hash function to the construction key value.Matching the rows of the construction table with the rows of the detection table is referred to as making a match (matchmaking) in this article, which occurs during the detection phase.

[0003] Join operations are widely used in Structured Query Language (SQL) processing. One widely used technique for implementing a join is to create a hash table that indexes one of the join operands and then probe the hash table with the other join operand. A typical implementation of this technique probes each value sequentially (i.e., one row at a time) as each record is processed.

[0004] This approach of probing the hash table sequentially (one row at a time) for each row in the probe table is inefficient, especially when applied to columnar data in memory (such as vectorized data), and does not take advantage of the properties and capabilities of modern computer system central processing units (CPUs) and memory controllers.

[0005] Hash Join is an important operator for RDBMS that supports analytical workloads such as reporting and data mining, because schema normalization often imposes a multidimensional data topology, such as a star or snowflake for data warehouses, which may require multiple joins for typical processing. To support hash joins, hash tables are often built to join data from two tables with similar join keys, such as for equijoins. However, there are some difficulties with efficient hash table data structures and algorithms:

[0006] • It may be difficult or impossible to accurately predict join selectivity and build table cardinality, which can be a critical factor in estimating the data distribution of a hash table as a prelude to establishing the initial capacity of the hash table.

[0007] Resizing a hash table is usually expensive. The more data that has been inserted, the more expensive the resizing is. Also, pausing insertions while the hash table is resizing is undesirable.

[0008] Probing hash tables usually takes up most of the query processing time because the probe table usually has more rows than the build table. The hash table formats of other methods are not suitable for accelerating probes and are therefore inefficient.

[0009] In general, other approaches involve data structures, formats, and algorithms designed for outdated computing styles and hardware. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In the attached picture:

[0011] Figure 1 is a block diagram depicting an example computer for joining rows of data based on an optimized arrangement and operation of a hash table;

[0012] Figure 2 is a flow chart depicting an example hash table probing process;

[0013] Figure 3 is a flow chart depicting an example hash table construction process;

[0014] Figure 4 is a block diagram depicting an example segmentation and indirection scheme for a hash table or another data map.

[0015] Figure 5 is a flow chart depicting an example parallel process for accelerating detection and / or construction.

[0016] Figure 6 is a flow chart depicting an example parallel process for accelerating detection and / or construction.

[0017] Figure 7 is a block diagram depicting an example computer that combines building and probing data rows based on an optimized selection of one category of data mappings from a plurality of categories of data mappings.

[0018] Figure 8 is a flow chart depicting an example computer process for dynamically selecting one of multiple categories of data mappings for performing a relational join.

[0019] Fig. 9is a flow chart depicting an example computer process for dynamically selecting one of multiple categories of data mappings for performing a relational join.

[0020] Fig.10 is a block diagram illustrating a computer system upon which embodiments of the present invention may be implemented;

[0021] Fig.11 is a block diagram illustrating a basic software system that may be used to control the operation of a computing system. DETAILED DESCRIPTION

[0022] In the following description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent that the present invention can be practiced without these specific details. In other cases, well-known structures and devices are shown in block diagram form to avoid unnecessary obscurity of the present invention.

[0023] General Overview

[0024] This paper is a novel implementation technique for accelerating relational joins and other methods. Several techniques are described for efficiently utilizing the vectorized processing power of a central processing unit (CPU) to build and probe hash tables, with application to in-memory columnar structured query language (SQL) database query processing.

[0025] The described algorithms fuse the inherent parallel nature of columnar data with the vector capabilities of modern CPUs to build and probe hash tables more efficiently than previous implementations. In addition, they better exploit the wide registers, superscalar execution, and memory hierarchy behaviors that are unique to current computer architectures.

[0026] This article is a technique for building and probing hash tables for tabular databases (such as relational databases) in an accelerated manner, with additional optimizations for columnar data (such as for columnar databases). In the prior art, hash table probing is usually done one key value at a time, one bucket at a time, one value lookup at a time, etc. This is a sequential process, which leads to subpar performance. The algorithm proposed in this article optimizes batch probing of hash tables. Therefore, most or all operations on data vectors are performed by processing multiple values ​​at a time, rather than processing one value at a time.

[0027] In an embodiment, various single instruction multiple data (SIMD) instructions can be used to perform the detection phase of the join operation in parallel. In one embodiment, SIMD is used to perform sixteen-key detection in parallel in only a few compact instruction sequences. The new parallelized detection of hash tables using SIMD instructions is two to three times faster than other detection methods.

[0028] The construction of the hash table for the detection phase of the connection is also optimized in this article. Sometimes it is more expensive to build a hash table than to detect. Therefore, it is very beneficial to use the technology described in this article to accelerate the construction phase. The technology in this article parallelizes the construction by using both the coarse-grained parallelization of threads and the fine-grained parallelization using SIMD. The coarse-grained parallelization such as task parallelization and the fine-grained parallelization such as data parallelization will be described in more detail below. The novel parallel construction of the hash table using SIMD instructions is two to three times faster than other construction phase methods.

[0029] The technology of this article is applicable to data organization operations of database systems, such as relational joins, but is also applicable to other kinds of organization operations, such as grouping and binning. The method of this article matches, groups or counts structured data, such as a one-dimensional vector of values ​​or a column of a database table or some other row set. Such participating columns or vectors are referred to as keys in this article. Therefore, a key is an ordered or unordered collection of values ​​referred to as key values ​​in this article. For example, July can be a key value stored in the month column of a database table grouped by month. In this case, the key is the month column as the grouping key.

[0030] Hash tables and other types of mappings herein can be used to match individual data items that should be context-dependent, such as for relational joins. In an embodiment, a hash table records which key values ​​appear in a data set, such as a one-dimensional vector (such as a column of a database). In an embodiment, a hash table additionally: a) counts duplicate key values ​​or accumulates other statistical data and / or b) retains references to source items (such as rows of a table or other row sets) or values ​​from source items. In such cases, a hash table can be used to obtain values ​​based on key values, such as counts, flags, or arrays of row identifiers. In this article, those values ​​mapped to, whether key values, other original or derived scalar values, or data structures, are referred to as entries.

[0031] In an embodiment, during a build phase of a hash join, a computer receives a request to access a build data row, each build data row being associated with a corresponding build key value. From a plurality of buckets of a hash table, a particular bucket containing a plurality of entries of corresponding build key values ​​in corresponding positions within a particular bucket is selected. Whether the particular bucket contains an entry of a build key value of a particular build data row is detected. Multiple positions within the particular bucket are concurrently checked to find an empty position to store an entry of a build key value of the particular data row. For the request to access the build data row, a response based on the hash table is sent.

[0032] In an embodiment, during a probe phase of a hash join, a computer receives a request to access a probe data row, each probe data row being associated with a corresponding probe key value. From a plurality of buckets of a hash table, a particular bucket containing entries of a plurality of corresponding build key values ​​is selected. The particular bucket is probed concurrently to detect whether the entries in the particular bucket include entries of the probe key value of the particular data row. For the request to access the probe data row, a response based on the concurrent probe of the particular bucket is sent.

[0033] In an embodiment, a computer receives a request for a relational join between a build data row and a probe data row. Based on the request for the relational join, a specific type of data mapping is dynamically selected from a plurality of types of data mappings that can implement the relational join. An instance of the specific type of data mapping is populated based on the build data row. A response is sent for the request for a relational join based on the probe data row and the instance of the specific type of data mapping.

[0034] 1.0 Sample Computer

[0035] Figure 1 1 is a block diagram depicting an example computer 100 in an embodiment. Computer 100 joins data rows 110 and 130 based on the optimized arrangement and operation of hash table 170. Computer 100 may be at least one rack server such as a blade, a personal computer, a mainframe, a virtual computer, or other computing device. When computer 100 includes multiple computers, these computers are interconnected through a communication network.

[0036] In various embodiments, the computer 100 provides access to a large-capacity data repository such as a relational database, a graph database, a NoSQL database, a column data store, a tuple data store (such as a Resource Description Framework (RDF) triple store), a key-value data store, or a document data store (such as for documents containing JavaScript Object Notation (JSON) or Extensible Markup Language (XML)). In any case, the data repository can be managed by software such as an application or middleware such as a database management system (DBMS). The data stored in the data repository can reside in volatile and / or non-volatile storage devices.

[0037] In this example, data is organized into fields, such as 120, 140, and other fields, as shown. In this example, the fields can have a logical and / or physical table format arrangement, so that the fields are arranged as one record per row and one field per column. For example, data rows 110 and 130 can each be a relational table, a column family, or an internal row set such as an intermediate result. For example, constructing data row 110 includes rows B1-B3.

[0038] A and B are example values ​​of fields 120 and 140 that may be stored in volatile and / or non-volatile storage devices. In operation, computer 100 receives or generates a request 150 to read and / or write data in a data repository. In an embodiment, request 150 is expressed as a data manipulation language (DML) such as a create read update delete (CRUD) statement or a query by example (QBE). For example, request 150 may be a structured query language (SQL) DML statement, such as a query. In an embodiment, request 150 is received via an open database connectivity (ODBC).

[0039] 1.1 Join processing using hash tables

[0040] Depending on the example, request 150 may directly specify (as shown) a relational join between data rows 110 and 130, or otherwise cause such a join to occur implicitly, such as by calling a database view or stored procedure whose implementation includes such a join. Although a single-field equal join is shown, other joins are possible, such as joins based on multiple fields, inequalities, and / or including nulls. As shown, request 150 specifies "build.field=probe.field", which requires joining data rows 110 and 130 based on the equality of fields 120 and 140.

[0041] The computer 100 performs a join for the request 150 in a build phase, followed by a probe phase. The build phase populates the hash table 170 based on the build data row 110. The build phase requires iterating through the values ​​in the field 120. For example, the build data row 110 can be a relational table whose rows B1-B3 are iterated during a table scan to access the contents of the field 120. In another example, the field 120 can be used as a one-dimensional vector such as in a random access memory (RAM). Therefore, it does not matter whether the build data row 110 is available in a row-major form or a column-major form.

[0042] Hash table 170 contains a fixed or increasing number of buckets, such as YZ. Each bucket YZ contains the same fixed number of positions, such as 0-1, which can be zero-based offsets in the bucket content array of the bucket. For example, the bucket and the bucket content array can be the same object. The position column in hash table 170 can be implicit and not actually stored.

[0043] Positions 0-1 are different offsets within the same bucket Y and should only be used for the same bucket Y. For example, multiple positions 0 in bucket YZ are independent positions that are not interchangeable. The computer 100 is careful not to calculate a position in bucket Y and then use the calculated position to access other buckets Z.

[0044] The build phase concurrently lists the corresponding field 120 values ​​A, B, A for B1-B3. Each occurrence of this value set has the opportunity to: a) insert a different or duplicate entry of the build key into the hash table 170, depending on the scenario, and / or b) assign or revise an element in the hash table 170. The structure of the entry depends on the scenario discussed later in this article. For example, the entry may or may not be the build key value shown.

[0045] Initially in this example, hash table 170 may contain empty positions 0-1 in bucket YZ. For example, position 1 of bucket Z is empty, as shown. When the build phase encounters value A for field 120 of row B1, various activities may occur depending on the scenario, such as the following.

[0046] As explained above, hash table 170 contains an array of buckets YZ. For example, YZ can be an offset into the array of buckets. In an embodiment, buckets YZ are continuous or discontinuous in memory. In an embodiment, positions 0-1 in the same bucket Y are continuous or discontinuous in memory.

[0047] Value A can be operated on as a hash code or as an input to a hash function that computes a hash code. Some or all bits of the hash code can be used as an offset into an array of buckets to identify the bucket. Value A hashes to bucket Y as shown.

[0048] After identifying bucket Y, various other activities may occur depending on the scenario, such as the following. An entry for value A may be stored as a constructed key value in the first empty position, which may initially be position 0. In this example, the entry may contain, directly or indirectly, via a reference data structure: a) value A, b) a hash code, c) an identifier or pointer to row B1, as shown in the element column, and / or d) other data, such as other fields of row B1.

[0049] Duplicate build key values ​​may be ignored or handled as follows: For example, the entry in position 0 in bucket Y may additionally or instead contain a count of the number of times the value A appears in field 120.

[0050] In this example, value A appears again in row B3 and is hashed again to the same bucket Y. As shown, value A and row identifier B3 are stored as shown to the next empty position in bucket Y, which may be position 1.

[0051] The value B of row B2 is hashed to bucket Z, as shown. Different hash codes and / or build key values ​​may be mapped to the same or different buckets. When the build phase ends, the contents of the build key column and element column are as shown. Thus, when the build phase ends, the population of hash table 170 is complete, and the probe phase may begin.

[0052] The probe phase matches the rows of probe data rows 130 to the rows of build data rows 110 by matching the values ​​of field 140 to the values ​​of field 120 as follows. The probe phase concurrently lists the corresponding field 140 values ​​B, A, A for rows P1-P3. Each occurrence of a value in this set of values ​​has a chance to be a probe key value to match a build key value in hash table 170. For example, value B for row P1 hashes to bucket Z and matches the build key value B in position 0.

[0053] Other join methods may require linear scans during the construction phase and / or the detection phase, which is slow. The technology herein does not perform linear scans. Therefore, the join herein is accelerated.

[0054] As explained above, bucket Y may contain duplicate build key values ​​A. Each occurrence of the same probe key value may match the duplicate build key value. For example, value A has duplicates in fields 120 and 140. For example, the join result is shown as response 180, which contains a pairing of an identifier of a row of build data row 110 with an identifier of a row of probe data row 130.

[0055] For example, the value A of the probe row P2 matches the build rows B1 and B3 of each hash table 170. Therefore, the response 180 contains P2xB1 and P2xB3. In this example, the response 180 is the final result that answers the request 150 and contains the join result. In another example, the join result is an intermediate result, and the response 180 is based on but does not contain the join result.

[0056] In various examples, the elements of hash table 170, the join results, and the response may require various amounts of materialization, such as projections. For example, some of the other fields of data rows 110 and 130 may be payload columns that may or may not be included in the join results and / or response 180. Some of the other fields that construct data row 110 may or may not be included in the elements of hash table 170.

[0057] As long as the row identifier or primary key is included in the join result and / or in the elements of hash table 170, the materialization of additional columns not directly involved in making a match can be deferred to various later stages of execution of request 150. For example, a projection may require additional columns, and all of the additional columns may not be materialized before generating response 180. The join result may include a row identifier for build data row 110 and / or a row identifier for probe data row 130, or neither.

[0058] 1.1 Row Identifiers and Duplicates

[0059] The implementation of the row identifier that uniquely identifies each row depends on the embodiment. Such implementations may include: a) a more or less persistent ROWID, such as a physical storage identifier or locator, b) a volatile row identifier, such as a volatile pointer, such as a memory address or array offset, or c) a candidate key. Candidate keys can be simple or composite. For example, the primary key of a table can be a candidate key. Different sets of rows may have different row identifier implementations.

[0060] For example, a persistent table may have a ROWID with an embedded disk block number (such as a logical block address (LBA) and a byte offset), while a volatile table such as one used for intermediate results may instead use a pointer as a row identifier. If the memory address is aligned to a unit larger than the smallest addressable unit (usually a byte), then the least significant bits of the pointer may be truncated so that the unused bits are implicit and either: a) reused for a bit field with non-addressable semantics, or b) not stored, such as to pack multiple pointer bits into a smaller space.

[0061] In an embodiment, a volatile row identifier is valid only until the row is evicted from the cache. For example, when the row is later reloaded into the cache in the same database session, the row is reassigned a different volatile row identifier. In an embodiment, a persistent row identifier is only permanent to some extent. For example, compression of a persistent table may cause a persistent row to be moved from one disk block to another, which may reassign a different ROWID to the row.

[0062] As shown and explained above, hash table 170 can store build key entries including build key values ​​and / or element columns of hash table 170. As shown, positions 0-1 in bucket Y contain corresponding occurrences B1 and B3 of the same build key value A. In other words, for each repeated occurrence of the same build key value, hash table 170 needs a separate position in the same bucket, which may be inefficient. For example, many duplicates may cause bucket Y to overflow, as discussed later in this article.

[0063] One difference between hash table 170 and hash table 171 is that hash table 171 integrates all repeated occurrences of the same build key value into the same build key entry, as discussed below. Thus, hash table 171 "clusters" repeated build key value occurrences. For comparative purposes, hash table 171 contains a superset of the contents of hash table 170. As shown, hash table 171 contains the build key value C that hash table 170 lacks.

[0064] The contents of buckets X and Z are alternative storage formats of otherwise identical content. Likewise, the contents of bucket W are a superset of the contents of bucket Y, as explained below.

[0065] In the illustrated hash tables 170 and 171, each hash bucket has two "positions": position 0 and position 1. Each position corresponds to a build key entry. For example, position 0 of bucket Y has a build key entry [build key A, element B1], while position 1 of bucket Y has a build key entry [build key A, element B3].

[0066] 1.2 Indicator Field

[0067] In the illustrated embodiment, position 1 of buckets X and Z is empty. In hash table 171, a position in a bucket is empty if all bits in the "indication" field of the build key entry at that position are zero. For example, a bucket can be initialized by setting all bits in the indication field of all positions in the bucket to 0. Within the indication field, 0...0000 depicts the number of zero bits. The actual number of bits depends on the embodiment.

[0068] The build key value B appears only once in each of hash tables 170-171. The build key entry for the build key value B appears in position 0 of bucket Z in hash table 170. In hash table 171, the build key entry for the build key value B is located in position 0 of bucket X. The indication field of the build key entry for the build key value B is shown as R...RR0. R...RR0 is a bit set with at least the least significant bit zero. Each R in the bit set is a bit of RID. RID will be discussed later in this article. RID can be a ROWID that identifies a row in a table or an intermediate row set. For example, each RID can be a pointer or an array offset. For example, one hash table can contain a pointer RID, while another hash table can contain an offset RID for the same or different row set.

[0069] Because not all bits of the build key entry containing the RID in hash table 171 are used for the RID, the RID should have fewer bits than the build key entry, because some bits of the build key entry may be needed for other purposes as discussed later herein. For example, the RID may be a truncated pointer with (one or more) implicit bits. RIDs, pointers, truncation, and offsets are discussed later herein.

[0070] 1.3 Dealing with build key conflicts

[0071] Bucket W contains build key entries for build key values ​​A and C. In this example, build key values ​​A and C create a "collision" by producing the same hash code. Although not shown, hash table 170 may have multiple different build key values ​​in the same bucket due to hash collisions. Collisions may cause deviations that were not present in the raw data of field 120. Whether caused by deviations in the hash function or by data skew in field 120, duplicate build key values, and to a lesser extent other collisions, may be mitigated as follows.

[0072] As explained above, position 0 in bucket W contains a build key entry representing two occurrences B1 and B3 of the same build key value A. For duplicates, the least significant bits of the build key entry are counter bit fields that count duplicates of the same build key value. Because duplicates involve at least two occurrences of the same build key value, the lowest / initial binary value of the counter as shown in the figure is 001, which represents a count of two. Incrementing the counter from two to three will change the binary value from 001 to 010.

[0073] In the indicator field of the build key entry in bucket W, P...P are the bits of a truncated pointer to an array of RIDs, so that P...P shown twice for build key values ​​A and C encode different corresponding pointers and therefore have different bit values. The array of RIDs is used for repeated occurrences of the same build key value. The value of the counter bit field of the build key entry indicates how many RIDs are stored in the array pointed to by the truncated pointer. As discussed later in this article, a truncated pointer is a prefix of a pointer that can be extended to a full pointer by appending some least significant bits that are implicitly zero.

[0074] The RID array has limited capacity, and incrementing the counter bit field may or may not require reallocating the RID array to have more capacity to store more RIDs. Likewise, the RID array may have excess capacity so that if the RID array has an empty slot, then a new RID where another duplicate appears is inserted into that slot and the counter is incremented, but the truncated pointer remains unchanged in the build key entry. Alternatively, if the RID array is full, then these existing RIDs are copied from the RID array to a larger RID array.

[0075] The new RID is also stored in the new RID array. The old RID array is discarded or returned to the pool for reuse, and the truncated pointer in the build key entry is reassigned to point to the new RID array. In any case, the counter bit field in the build key entry is incremented.

[0076] 1.4 Handling counter bit overflow

[0077] As explained above, the counter bit field in the indication field counts how many RIDs are stored in the RID array for the indication. Overflow of the counter bit field is avoided as follows. When the counter increments to the maximum binary value of all ones (as shown for build key value C), the following occurs: a) the existing RID is copied from the RID array to a larger self-describing RID array that has a counter that counts how many RIDs are stored in the new RID array, b) the new RID is stored in the new RID array, and c) the counter bit field in the build key entry remains frozen at all ones, as shown, so that increments for subsequent duplicates occur using the counter in the new RID array rather than the counter bit field in the build key entry.

[0078] To avoid further counter overflows, the counters in the new RID array are wider than the counter bit fields, and wide enough so as to never overflow. If the new RID array itself (rather than its counters) overflows, then a larger self-describing RID array can replace the current self-describing RID array, which requires copying the RIDs into the larger RID array and reassigning the truncated pointers in the build key entries. In an embodiment, each new self-describing RID array is exponentially larger than the RID array it replaces for the same position in the same bucket.

[0079] In one such embodiment, an exponential increase requires a doubling of the size. As discussed later in this article, exponential size designs are well suited for data skew. In an embodiment, a new RID array of a fixed or larger size does not replace the old RID array, but is instead appended or appended to a linked list of RID arrays that forms a segmented array for the same position of the same bucket.

[0080] Data skew is an example of different join keys appearing at different frequencies in fields 120 and / or 140. With RID and pointer encoding in the build key entries of build key values ​​AC in hash table 171, the information density of the build key entries is inversely proportional to the frequency. That is, build key value B is the least frequent, but the build key entry for build key value B is the densest because it encodes the RID directly, rather than encoding a pointer for indirect access.

[0081] Build key A is more frequent, and has a lower density of build key entries because it counts but does not encode the RID. Build key C is the most frequent, but has the lowest density of build key entries because it neither encodes nor counts the RID.

[0082] At this inversely proportional information density, there is a counter-intuitive reduction in memory consumption because even if build key C occurs the most times (e.g., ten times), those ten occurrences share the same cluster build key entry. Here, clustering requires repeated build keys. And a separate build key entry is required for each singleton build key (such as build key B). Here, singleton means no duplicates. Therefore, even if the singleton build key is less than the repeated occurrences of build key C, the singleton build key can be more than the cluster build key. Therefore, counter-intuitively, the space savings of the denser singleton build key entries can exceed the space cost of the less dense cluster build key entries.

[0083] Likewise, the information density of the build key entries for build key C is less than that of build key A, as explained above, even though build keys A and C both have clustered build key entries. However, the lower density for build key C is a space cost that is amortized over more duplicates than for build key A because build key A is less frequent. In these ways, the build key entries of hash table 171 are optimized in space.

[0084] 2.0 Example Detection Process

[0085] As explained earlier herein, a hash join may require a build phase to populate the hash table 170 , followed by a probe phase to make matches using the hash table 170 . Figure 2 An example detection phase is depicted. Figure 3 Depicts example build stages.

[0086] For example, and as explained later herein, without fusing the operators from the two stages, the computer 100 may execute Figure 3 The construction process is then subsequently executed for the same hash table 170 Figure 2 However, this paper first presents Figure 2 , because some embodiments of the detection phase can be slightly simpler than the construction phase. Figure 1 Let's discuss Figure 2-3 .

[0087] Figure 2 is a flow chart depicting an example probing process for joining data lines 110 and 130. In an embodiment, a novel speedup of the probing phase is provided by probing multiple entries in hash table 170 concurrently, such as using single instruction multiple data (SIMD) as described later herein.

[0088] Step 202 receives a request 150 for a relational equijoin of data rows 110 and 130 that specifies or implies a relation based on fields 120 and 140. In an embodiment of step 202, a query planner, optimizer, and / or compiler converts the request 150 into an interpretable or executable form, such as a database operator tree. In an embodiment, the construction phase and the detection phase of the join are implemented by corresponding operators in the tree.

[0089] In an embodiment, the table scan operator is fused (i.e., combined) with the build operator for the build phase. In an embodiment, the probe operator of the probe phase is fused with a payload operator that supplements the join result with additional fields, such as other fields of the projection of data rows 110 and / or 130. For example, an element of hash table 170 may contain some or all of the other fields of the build data row 110.

[0090] Such as Figure 3 A construction phase such as the process of may occur between steps 202 and 204. Step 204 assumes that the hash table 170 has been populated, such as by the construction phase. The construction phase may be followed by a detection phase such as the following.

[0091] In one example, the construction data row 110 is used in the construction phase, and the detection data row 130 is used in the detection phase. Depending on the embodiment and scenario, the data rows 110 and 130 may be different in semantics, format, and / or content, but are somewhat interchangeable for the corresponding data sets used in the join. In an embodiment, the computer 100 may decide which of the two data sets is used in the construction phase and the other data set is to be used in the detection phase. For example, the detection data row 130 may be used in the construction phase instead, and the construction data row 110 may be used in the detection phase.

[0092] The probe phase includes steps 204 and 206, which may be repeated for the corresponding probe key value of each row in the probe data row 130. The probe data row P1 has the value B of the field 140 as its probe key value. From the buckets YZ of the hash table 170, step 204 selects a bucket Z containing zero or more entries of the same or different constructed key values ​​based on some or all bits of the value B or some or all bits of the hash code of the value B.

[0093] Step 206 matches the corresponding probe key value (i.e., field 140) of the probe data row 130 with the corresponding element of the hash table 170. The probe key value is iteratively used in step 206 to match the probe key value with an element of bucket Y or Z by concurrently comparing part or all of the probe key value or its hash code with all or part of the build key value or hash code in the bucket without linear scanning. The concurrent comparison is novel and will be discussed later in this article.

[0094] Step 206 produces the join result. Step 208 sends a response 180 that answers the request 150. Depending on the example: a) the join result may be the response 180, b) the response 180 may contain the join result and additional data, c) the response 180 may contain some vertical and / or horizontal slices of the join result, or c) the response 180 is otherwise based on but does not contain the join result.

[0095] 3.0 Example Build Process

[0096] Figure 3 is a flow chart depicting an example build process for populating hash table 170 based on build data row 110. In an embodiment, a novel speedup of the build phase is provided by concurrently accessing multiple entries in hash table 170, such as using single instruction multiple data (SIMD) as described later herein. In an embodiment, the build phase is more complex than the subsequent probe phase.

[0097] Step 301 receives a request 150 that specifies or implies a relational equijoin of data rows 110 and 130 based on fields 120 and 140. Although shown as separate steps in separate processes, steps 301 and Figure 2 Step 202 may be the same step of receiving request 150. Except as explained elsewhere herein, steps 202 and 301 are combined into a single step.

[0098] The construction phase includes steps 302-305, which may be repeated for the corresponding construction key value of each row in the construction data row 110. The construction data row B1 has the value A of the field 120 as its probe key value. From the buckets YZ of the hash table 170, step 302 selects a bucket Y containing zero or more entries of the same or different construction key values ​​based on some or all bits of the value A or some or all bits of the hash code of the value A.

[0099] Both the build phase and the probe phase use the join key value to find the bucket. In an embodiment, steps 302 and Figure 2 Step 204 of is a separate step in a separate phase that shares the same step implementation. For example, steps 204 and 302 may be separate calls to the same subroutine, even though step 302 uses the build key value of build data row 110 and step 204 uses the probe key value of probe data row 130. That is, both the build key and the probe key are join keys and may be partially processed in the same manner (such as for equi-joins) in various examples.

[0100] Which subset of steps 303-305 occurs for any data row in build data row 110 may depend on: a) whether a duplicate is possible, b) whether value A is a duplicate, c) whether the duplicate is related to request 150, and / or d) whether the duplicate should be integrated or kept separate. Table 1 below shows the steps after step 302 based on the following build scenarios 311-315 and conditions for each row in build data row 110. Different rows in the same build data row 110 may require the same or different corresponding build scenarios.

[0101] Thus, different corresponding subsets of steps 303-305 may occur for different rows of build data. For example, the first occurrence of value A is not a duplicate, but the second occurrence of the same value A is a duplicate. Thus, different occurrences of the same value A may or may not result in different build scenarios. Likewise, the behavior of the same step may or may not differ based on which build scenario value A results in.

[0102] Build the scene Are duplicates possible? Is it a duplicate? Duplicate handling Subset of steps 311 no 304-305 312 yes no 303-305 313 yes yes Ignore by skipping 303 314 yes yes integrated 303，305 315 yes yes Keep it separate 303-305

[0103] In the build scenario 311, it is not possible to repeat the build key value so that each build data row has a different corresponding build key value, such as in the following cases: a) the relational schema indicates that the field 120 has different values, b) the build data row 110 is an intermediate result based on row aggregation, such as using grouping, so that the field 120 necessarily has different values, or c) a scan or index scan or other inspection of the build data row 110 empirically indicates that the field 120 has different values ​​by chance. For example, a coding dictionary for the field 120 dynamically generated for a relational table or memory compression unit (IMCU) containing as many dictionary codes as rows in the build data row 110 may or may not indicate that the field 120 has different values ​​by chance. IMCU will be discussed later in this document.

[0104] Step 303 detects whether hash table 170 already contains the current build key. If hash table 170 already contains the build key, then step 305 occurs. Otherwise, the build key is not a duplicate, and step 304 occurs as follows. Step 303 will be discussed further later in this article.

[0105] Step 304 concurrently finds empty positions in all positions 0-1 within bucket Y. In an embodiment, an empty position is represented as an entry storing an empty join key value. In this case, steps 304 and Figure 2 Step 206 is a separate step in a separate phase that shares the same step implementation.

[0106] For example, steps 206 and 304 can be separate calls to the same subroutine, since both the null key value and the probe key value are join keys that can be partially processed in the same manner in various examples. Regardless of whether the null key value represents an empty position, steps 206 and 304 can have similar parallelization. When bucket Y contains multiple empty positions, an empty position is selected according to a criterion that depends on the embodiment.

[0107] Step 305 stores or adjusts an entry of value A as the build key value for build data row B1 in a location within bucket Y. The behavior of step 305 and the location within bucket Y depend on the build scenario. For build scenarios 311-312 and 315: a) the location is an empty location found by step 304, and b) a new entry of value A is stored into the empty location.

[0108] In construction scenario 312, construction data row B1 has the first or only occurrence of value A, even though duplicates are possible. In this case, step 303 detects that value A is not a duplicate. Regardless of the construction scenario and whether value A is a duplicate, step 303 occurs as follows.

[0109] As explained above, step 303 detects whether bucket Y contains an entry with value A as the build key value for build data row B1. In an embodiment, steps 303 and Figure 2 Step 206 is a separate step in a separate stage that shares the same step implementation. For example, steps 206 and 303 can be separate calls to the same subroutine, because both the build key and the probe key are join keys that can be partially processed in the same way in various examples, such as for equi-joins.

[0110] Therefore, steps 206 and 303 can have similar parallelization. Step 303 can compare value A with multiple entries of the same or different values ​​in the same bucket Y at the same time without linear scanning.

[0111] In build scenarios 313-315, step 303 detects that value A is a duplicate. In build scenario 313, the duplicate is irrelevant to request 150, and building data row B3 should be ignored by skipping steps 304-305 for building data row B3. For example, request 150 may be an online analytical processing (OLAP) query that filters using an equijoin of a fact table and a dimension table, but response 180 does not include the fact table and only projects the dimension table.

[0112] For example: a) a purchase order may be a fact, b) a dimension table may classify products, and c) the response 180 indicates only products for which there are no purchase orders. This assumes that the build data row 110 is a fact (i.e., a purchase order). An embodiment is free to use either the fact table or the dimension table for the build phase, and the other table for the probe phase. In an embodiment, whichever of the table or input row sets has fewer rows is used as the build data row 110. Other criteria for specifying which input row set is used as the build data row 110 include: which input row set consumes less volatile memory, which input row set has more distinct key values, and which input row set has less data skew. In an embodiment, the dimension table is always used as the build data row 110.

[0113] In build scenario 314, duplicates should be integrated, which requires adjusting the existing entry for value A in bucket Y. For example, the element column of hash table 170 may instead contain a count of occurrences of value A that should be incremented each time value A appears again. Build scenario 314 skips step 304, which would find an empty location in bucket Y, because build scenario 314 reuses the already existing entry for value A found by step 303.

[0114] like Figure 1 As shown in , when value A appears again, build scenario 315 inserts another entry of duplicate value A into the same bucket Y. For example, response 180 may report different purchase orders for the same product. In any case, build scenario 315 requires steps 303-305 as described above.

[0115] After all build data rows B1-B3 are processed according to the corresponding build scenario, the population of hash table 170 is completed and step 306 occurs. In most cases, Figure 2 The detection process may occur more or less immediately before step 306. In this case, steps 306 and Figure 2 Step 208 is an identical occurrence of the same step of sending the same response 180 answering the same request 150. Thus, steps 208 and 306 may be combined to send only one response 180.

[0116] In an embodiment, hash table 170 may be reused in various ways. For example, subsequent joins for the same or different requests may skip the build phase ( Figure 3 ), and the detection phase ( Figure 2) Reuse hash table 170 for the same or different probe data rows. For example, three relational tables AC may have similar join columns ac, which are used in two equi-join unions, such as Aa=Bb OR Aa=Cc. In this case, table A may be used in the build phase to populate hash table 170, while the remaining two tables BC may be used in the respective separate probe phases, both of which use the same hash table 170 for the respective separate joins.

[0117] 4.0 Example Join Key Configuration

[0118] As explained earlier herein, fields 120 and 140 are used as join keys, which may be build keys or probe keys. Depending on the embodiment and use case, join keys may be formatted and / or used in a particular manner, referred to herein as join key configurations. In addition to the example join keys already presented herein, Table 2 below lists additional example join key configurations 631-634, some or all of which may be operated by computer 100 in various embodiments.

[0119] Connection key configuration meaning 631 Grouping Key 632 Composite candidate keys 633 A set of field(s) that are not candidate keys 634 Encoding dictionary code

[0120] In join key configuration 631, field 120 or 140 may be used as both a grouping key and a join key. For example, request 150 may be a SQL containing a GROUP BY clause specifying field 120, even if field 120 is not a candidate key such as a primary key of a relational table. Grouping keys often contain duplicates.

[0121] In join key configuration 632, multiple fields of the same relational table or set of data rows (such as 110 or 130) can be used together as both a composite candidate key and a composite join key. When a join key is a candidate key, there are no duplicates because the candidate key should uniquely identify each row. In various examples, only the build key is a candidate key, or only the probe key is a candidate key, or neither is a candidate key, or both are candidate keys. In the example, the equal join key: a) appears as field 120 and field 140, b) is a candidate key for the dimension table, but not a candidate key for the fact table to be joined to the dimension table, and c) has duplicates in the fact table but not in the dimension table.

[0122] In join key configuration 633, the composite join key is not a candidate key. In join key configuration 634, the join key is dictionary encoded. Each different unencoded value of the join key can correspond to a corresponding different dictionary code. In an embodiment, the unencoded values ​​are sparse, and the dictionary codes are dense, such as consecutive integers.

[0123] 5.0 Example Entry Configuration

[0124] Depending on the embodiment and use case, the construction key entry can be formatted and / or used in a particular manner, referred to herein as an entry configuration. As explained above, a bucket can store multiple entries of the same or different construction key values. And as explained above, various embodiments of hash table 170 can have different corresponding construction key entry formats, which may or may not be designed for concerns such as hash codes, duplicates, and pointers.

[0125] Table 3 below lists example entry configurations 611-617, some or all of which may be operated by computer 100 in various embodiments. Additional entry configurations will be presented later.

[0126] Entry Configuration meaning 611 Constructing the join key value of the data row 612 Hash code of the join key value 613 Count of repeated occurrences of the same build key value 614 Construct the other fields (one or more) of the data row 615 For duplicates integrated for the same constructed key value, the extreme value of another field of the duplicate row 616 For duplicates integrated for the same constructed key value, the central tendency of another field for the duplicate rows 617 Pointer to the entry data

[0127] Entry configuration 611 stores some or all of the bits of the constructed key value directly within a key entry in hash table 170. In this case, the key entry includes at least the constructed key columns shown in hash table 170.

[0128] The entry configuration 612 stores some or all bits of the hash code of the build key directly in the key entry in the hash table 170. In some cases, the hash code may contain fewer bytes than the build key, such as for text build keys and integer hash codes. In an embodiment, space is saved when the key entry contains the hash code instead of the build key.

[0129] In most cases, the hash code in the dependent key entry is not exact, which may cause conflicts when different join key values ​​have the same hash code, and may also cause false hits (i.e., false positives). Conflicts may require additional logic to disambiguate. In an embodiment, disambiguation is delegated to application-specific logic that can compare other fields of the data row 110 or 130 to establish which build key value the key entry actually represents. In an embodiment, the key entry itself contains data, such as an element column of a hash table 170 or a pointer to a build data row or other data that can be used in a general manner for automatic disambiguation by the DBMS itself.

[0130] The entry configuration 613 maintains a count of repeated occurrences of the same build key value directly in the key entry, such as for SQL using COUNT and GROUP BY. The entry configuration 614 stores other field(s) of the build data row 110 directly in the key entry, such as a primary key or a materialized field, such as for a projection, such as for a response 180 or an intermediate result. If the build data row 110 itself is an intermediate result of an earlier join when the request 150 has multiple joins such as a multi-way join (such as Aa=Bb=Cc), then the key entry can contain field(s) from multiple relationship tables.

[0131] Entry configurations 615-616 support repeated occurrences of the same build key value by integrating into the same key entry, such as for a SQL GROUP BY with a SQL aggregate function such as SUM. Entry configuration 615 maintains another field or calculated extreme value, such as MAX, for each build data row with the same build key value. Entry configuration 616 maintains another field or calculated central tendency value, such as STDDEV or AVG, for each build data row with the same build key value.

[0132] The entry configuration 617 stores a pointer or offset to a build data row or other data associated with the build data row. Various examples include: a) a pointer to a data row in a row cache or a database block in a buffer cache, b) a persistent row identifier such as a ROWID, or c) a volatile offset to a vector of row identifiers (such as a primary key), or a volatile offset to a collection of IMCUs for the same relational table or set of rows. In an embodiment, an integer offset may be narrower than a pointer, or a pointer may be multi-byte aligned so that the least significant bit is always: zero, implicit, not stored, and / or reused as a bit field(s).

[0133] 6.0 Example Bucket Configuration

[0134] Figure 4 4 is a block diagram depicting an example segmentation and indirection scheme for a hash table or another type of data mapping as presented later herein. As shown, a key-value (KV) table 400 may be a hash table or other type of data mapping. For example, a KV table 400 may be Figure 1 Implementation of hash table 170 .

[0135] Table 4 below lists example bucket configurations 621-623, some or all of which may be incorporated into KV table 400 in various embodiments. Additional bucket configurations will be presented later.

[0136] Bucket Configuration meaning 621 Buckets are segmented arrays 622 Buckets or segments are no larger than a hardware cache line 623 Buckets or segments have the same memory address alignment as hardware cache lines

[0137] In bucket configuration 621, each bucket may be a segmented array to accommodate overflow. Bucket segmentation as discussed later herein is different from table segmentation, as described below.

[0138] In an embodiment, the KV table 400 is an array of buckets (such as QX) such that some or all bits of a hash code or build key value can be used as an index in the array to identify the bucket. In the illustrated embodiment, the KV table 400 is a segmented array of expandable buckets QX such that each table segment (such as 430) contains an array of buckets. The table segment 430 itself is a contiguous area of ​​memory, but multiple table segments in the KV table 400 may or may not be discontinuous with each other. Depending on the embodiment or scenario, the KV table 400 may: always contain the same fixed number of table segments and base pointers, or grow additional table segments and base pointers as needed during the construction phase.

[0139] As shown, KV table 400 has four table segments (including 430), each of which contains four buckets, so that KV table 400 contains a total of 4x4=sixteen buckets. For example, a table segment contains buckets QT that are consecutive to each other, and another table segment contains buckets UX. As shown, each of the base pointers 0-3 shown points to a corresponding table segment in KV table 400. For example, base pointer 1 points to table segment 430. In this way, KV table 400 can be a segmented hash table, which is different from a hash table with segmented buckets, but a hash table can be both segmented and have segmented buckets, as explained later in this article.

[0140] The hash table of the segments is decomposed into disjoint bucket subsets so that in an embodiment and whenever the following occurs, each table segment itself can be a smaller hash table with a corresponding subset of the buckets of the KV table 400. For example, as shown, the KV table 400 has four segments, and in an embodiment, each segment can be constructed and probed with different key value sub-ranges that ensure mapping to the corresponding bucket subset of the hash table segment. This may require horizontal partitioning of the constructed and / or probed data rows by joining key values. In an embodiment, there is symmetric multiprocessing (SMP), such as each processor core having one or more table segments for task parallelization.

[0141] In an embodiment not shown, the bucket has a fixed capacity to contain multiple build key entries. In the illustrated embodiment, the bucket has a more or less unlimited capacity, and a bucket segment can be allocated one at a time as needed. Each bucket segment has the same capacity to store multiple entries of the same or different build key values.

[0142] Depending on the embodiment, the array of buckets QX of KV table 400: a) directly stores each bucket of the same fixed capacity, b) in the illustrated embodiment, directly stores the corresponding first segment of the same fixed capacity of each bucket of unlimited capacity, or c) indirectly stores a pointer or offset to the corresponding first segment of each bucket of unlimited capacity. For example, for (b) shown, the table segment contains a bucket segment, such as bucket segment 440, as the corresponding first segment of each bucket in the table segment. For example, bucket segments 440 and 423 can be daisy-chained in this order, as shown by the arrow marked NEXT, to provide a linked list of bucket segments to expand the storage capacity of the bucket.

[0143] In the illustrated embodiment, each bucket segment contains a pointer or offset to the next segment of the same bucket, so that each bucket is a segment array based on a linked list of bucket segments. In an embodiment, bucket segments of all buckets of the same or different hash tables are pre-allocated in the same array, shown as overflow bucket segments 410, whose elements include individual overflow bucket segments 421-423, so that the links in the linked list of buckets can be offsets to the array of overflow bucket segments 410. For example, the offset can be narrower than the address pointer.

[0144] For example, the overflow bucket segment 410 can operate as a pool from which the spare bucket segments can be taken and later returned when the KV table 400 is discarded. In an embodiment, the bitmap indicates which spare bucket segments 421-423 currently participate in the linked list of any bucket. In an embodiment without a pool not shown, the bucket segments of the same bucket have exponentially increasing capacities (such as powers of two) to save space when the bucket is small and to save repeated segment allocation time when the bucket is large.

[0145] In bucket configuration 622, each bucket or bucket segment has the same fixed size that is no larger than a hardware cache line, such as an L1, L2, or L3 cache of a central processing unit (CPU) or processor core, so that the bucket or bucket segment can always fit into the hardware cache line. Thus, frequently accessed buckets are cached to exploit temporal locality, such as due to data skew of join key values ​​during the build phase and / or the probe phase.

[0146] In bucket configuration 623, each bucket or bucket segment has the same multi-byte memory address alignment as a hardware cache line. For example, when a hardware cache line is 64 bytes wide, bucket segments are aligned to 64-byte boundaries so that the six least significant bits of a bucket segment address are always: zero, implicit, not stored, and / or reused as bit field(s).

[0147] 7.0 Example Types of Prefetch Data

[0148] Buckets and hash tables are data structures that aggregate data, as explained earlier in this article. These data structures can provide regular organization of data, such as when data items have uniform fixed sizes and / or address alignment, which helps data parallelism for acceleration, such as for vector processing. Especially for data parallelism such as SIMD operations, memory latency can reduce throughput, which can be mitigated by caching data pre-fetched from main memory into hardware cache.

[0149] Embodiments may use software prefetching, such as prefetch instructions for an instruction set architecture (ISA). The term "stride" refers to the number of bytes or data items that are prefetched concurrently. The DBMS may or may not calculate the stride based on SIMD register width and / or time predictions (such as clock cycles, such as based on static or timely considerations of machine instruction sequences and / or memory wait states). In an embodiment, the demarcation of the stride is calculated by a just-in-time compiler such as a query compiler, a bytecode compiler, and / or an optimizing analyzer. In an embodiment, the stride demarcation is hard-coded, such as hand-coded in a text source code.

[0150] Table 5 below lists example categories of prefetch data 641-644, some or all of which may be used by computer 100 in various embodiments. In an embodiment, each of prefetch data 641-644 is a stride of multiple data items of the same kind, such as horizontal and / or vertical slices at a memory address or offset within an array. In an embodiment, multiple items with the same or different strides are contiguous in main memory and are copied directly into the hardware cache by prefetching.

[0151] Prefetch data meaning 641 Multiple buckets or bucket segments 642 Multiple join key values 643 Precomputed hash codes for multiple join key values 644 ROWID, primary key, or other fields of multiple rows

[0152] Prefetch data 641 is a plurality of buckets or corresponding segments of a plurality of buckets, any of which have the same fixed size. Prefetch data 642 is a plurality of join key values ​​of data row 110 or 130. Regardless of how the hash codes of the plurality of join key values ​​are calculated, such as whether they are calculated concurrently, these hash codes can then be stored consecutively in the memory providing prefetch data 643.

[0153] Other prefetch data 644 may be associated with the corresponding data row 110 or 130, such as a ROWID, a primary key, other fields, or the entire data row itself. The final prefetch of data items for all data rows 110 or 130 may or may not require multiple strides in sequence, and the timing may be application specific so that the previous stride does not need to be followed immediately by the next stride, such as when the prefetch stride is faster than the processing stride. In an embodiment, stride prefetching and stride processing occur in the same computational thread and / or machine instruction sequence.

[0154] 8.0 Example Parallelization of Hash Join Operations

[0155] As explained earlier in this article, the build phase may search within the bucket to find: a) an existing entry that duplicates the build key, or b) an empty location. Therefore, the build phase and the probe phase may require some similar search activities. Figure 5 is a flow chart depicting an example parallel process for accelerating detection and / or construction. Figure 1 Let's discuss Figure 5 .

[0156] Steps 501 and 503 illustrate pipeline parallelization of prefetching. As described above, although all data lines 110 or 130 are ultimately traversed in a single pass, prefetching large load data to keep the hardware cache warm would otherwise significantly increase the observable latency to main memory even with the hardware cache. The following example prefetching provides pipeline parallelization to increase throughput.

[0157] Each of steps 501 and 503 requires at least two strides of the same or different corresponding types of data in the same or different corresponding ways, respectively. Step 501 pre-fetches the current stride of a data item while processing the previous stride of the same data item. As discussed below, strides of multiple corresponding types of data items may also be pre-fetched simultaneously.

[0158] Step 502 concurrently calculates corresponding memory addresses for multiple buckets or bucket segments, such as through SIMD, superscalar, or superpipeline discussed below. Step 502 can concurrently convert multiple hash codes or join key values ​​to memory addresses of corresponding same or different buckets. When multiple same or different hash codes or join key values ​​belong to the same bucket or segment, step 502 calculates duplicate addresses.

[0159] Step 503 can be implemented as concurrently occurring steps 503A-503B (not shown). The stride of one data item and the stride of another data item can be pre-fetched simultaneously. At the same time, step 503A pre-fetches corresponding buckets or segments for some multiple data rows, while step 503B pre-fetches hash codes or join key values ​​for the same or other multiple data rows of the same row set. For example, step 503A can use the bucket or segment address calculated by step 502. Multiple strides can be pre-fetched more or less simultaneously by executing multiple corresponding pre-fetch instructions in rapid succession, such as when the pre-fetch stride is slower than when multiple instructions are placed into the CPU instruction execution pipeline.

[0160] Step 504 executes one of various CPU parallelization instructions to execute a corresponding one of steps 504A-504C (not shown). Steps 504A-504C are mutually exclusive concurrent scanning methods based on the embodiment. In other words, the embodiment executes a corresponding one of steps 504A-504C. As used herein, concurrent scanning is neither linear scanning nor sequential scanning.

[0161] Step 504A executes individual single instruction multiple data (SIMD) instructions of an instruction set architecture (ISA) that concurrently scans multiple key entries in the same bucket or bucket segment to find: a) an entry for a given join key value during a build phase or a probe phase, or b) an empty position in a bucket or segment during a build phase. In an embodiment, the same SIMD instruction is repeatedly executed segment by segment in a linked list of segments of the same bucket until a given key entry or an empty position is found or there are no more segments in the linked list.

[0162] The superscalar processor executes multiple instructions concurrently. In a scalar embodiment, these same multiple instructions are instead executed sequentially by the scalar processor. Step 504B is performed by the superscalar processor concurrently executing multiple instructions, each instruction comparing the same or different key entries with corresponding entries in corresponding positions of the same bucket or segment. For example, if the bucket contains two positions, each position can be checked by a corresponding one of two similar instructions, then the superscalar processor concurrently executes the two instructions to concurrently check whether the two positions have a given key entry or an empty position.

[0163] A super-pipelined processor: a) divides a CPU clock cycle into sub-cycles, b) concurrently executes multiple pipeline stages of the same instruction during the same CPU clock cycle, and c) initiates another instruction in each sub-cycle, so that many instructions that partially overlap in time are executed. In another embodiment, these same many instructions are instead initiated separately at corresponding CPU clock cycles on a normal CPU. Step 504C is performed by the super-pipelined processor concurrently. Multiple instructions, each instruction compares the same or different key entries with corresponding entries in corresponding positions of the same bucket or segment. For example, if the bucket contains two positions, each position can be checked by corresponding instructions in two similar instructions, then the super-pipelined processor concurrently executes two instructions to concurrently check whether the two positions have a given key entry or an empty position.

[0164] In an embodiment, when the bucket is a segmented array, the address of the first segment is calculated as discussed above in step 502. In an embodiment, step 504A sequentially uses various SIMD instructions to concurrently traverse multiple linked lists of segments of the corresponding bucket.

[0165] In the same bucket or different buckets, when duplicates occur, step 505 concurrently adjusts multiple entries of the same or different constructed keys. For example, individual SIMD instructions may concurrently update data directly or indirectly contained in multiple key entries.

[0166] 9.0 First Exemplary Embodiment

[0167] The following exemplary embodiment with pseudo code demonstrates implementation options that can be used with some or all of the embodiments previously presented herein. Features of this exemplary embodiment are not requirements of the embodiments previously presented herein.

[0168] This exemplary embodiment demonstrates neutrality of the following architectures: a) CPUs with SIMD processing lanes and / or SIMD wide registers, b) main memory, c) mass storage data formats, such as row-major, column-major, relational schema, and / or database blocks, and d) multithreading, such as for multi-core CPUs. This exemplary embodiment may or may not use an Intel CPU, such as a Pentium 4 or Xeon, both of which have exemplary SIMD instruction set architectures (ISAs) that provide data parallelization feature sets, such as Multimedia Extensions (MMX), Streaming SIMD Extensions (SSE), and Advanced Vector Extensions (AVX).

[0169] In a multithreaded scenario, thread safety can be ensured by a) hardware synchronization, such as atomic instructions or cache coherence instructions of the ISA, such as memory barriers or fences, b) software synchronization, such as mutexes, semaphores, or critical sections, or c) horizontal partitioning of data by join keys or hash codes so that multiple computation threads do not share buckets, such as a hash table for partitions. For example, SQL aggregate functions can rely on atomic instructions such as fetch-and-add, and daisy chains of segments of the same bucket can grow without contention with compare-and-swap atomic instructions.

[0170] 9.1 Compression Units in Memory

[0171] Those are examples of coarse-grained thread parallelism, such as for multi-core or hyperthreaded CPUs that can complement and further accelerate fine-grained data parallelism of SIMD or other vector hardware. For example, each computational thread can asynchronously apply the same logic to a separate corresponding subset of data rows 110 or 130 available in a separate corresponding in-memory compression unit (IMCU). An IMCU contains continuously stored values ​​of one or more columns from a database table or intermediate result set. The structure and operation of an IMCU are as follows.

[0172] For example, in a dual-format database system, one of the formats in which data is available for query processing is based on the on-disk format, while another format in which data is available for query processing is independent of the on-disk format.

[0173] The format corresponding to the on-disk format is referred to herein as the "persistent format" or "PF". Data in the persistent format is referred to herein as PF data. A memory format that is independent of the on-disk format is referred to as a "mirror format" or "MF". Data in the mirror format is referred to herein as MF data. For example, in one embodiment, the persistent format is a row-based block format, while the mirror format is a column-based format. This dual-format database system is described in U.S. patent application numbered 14 / 337,179, entitled "Mirroring, In Memory, Data From Disk To Improvement Query Performance" (hereinafter referred to as the "Mirror Application"), the contents of which are incorporated herein by reference.

[0174] MF data can be organized within volatile memory into "in-memory compression units" (IMCUs), which contain (one or more) vectors that contain consecutive values ​​of one or more columns from the same set or subset of rows. Therefore, an IMCU can be at least a vertical slice of a database table, and when the IMCU only involves a subset of rows, the IMCU is also a horizontal slice of the database table. Due to the columnar format and continuous storage of column values, IMCUs can facilitate data-parallel vector processing, as shown below. In addition, because when the same (one or more) columns are horizontally sliced ​​(i.e., horizontally partitioned) into multiple IMCUs, these IMCUs can be regarded as segments of the column, so that each IMCU can be processed concurrently by a corresponding processor core, as discussed earlier in this document.

[0175] 9.2 Various forms of parallelization

[0176] Regardless of whether data rows 110 or 130 are stored in IMCUs, the size of the hash table buckets is designed to constrain unused space to a specified portion of the total space consumed by the hash table, and to constrain the maximum number of bucket segments that are linked together for each hash key value. In this design, the size of the hash buckets is designed to interact efficiently with the memory and vector architecture. This means that their size is fixed to the unit retrieved from memory (the "cache line size"), and the size of the hash table is set so that most probes succeed in one bucket segment retrieval.

[0177] This organization has many benefits. First, lookup operations can be efficiently pipelined, such as by prefetching, because the mapping from lookup key values ​​to buckets is generally correctly predicted and performed consistently. Second, because each lookup key value is independent, multiple of these mappings can be done in parallel when the CPU has superscalar or explicit vectorization or both.

[0178] Another important implementation detail is that for each use case of the hash table, such as depending on the join key type, the internal layout of the bucket is specialized to maximize the number of key values ​​it stores, and bucket searches are enabled using vector instructions. This results in an execution model where execution alternates between cross-bucket parallelism and intra-bucket parallelism, both using SIMD in the same or different computation threads, which maximizes utilization of memory system and CPU resources.

[0179] The presence of additional elements helps improve the efficiency of the design. Following a chain is not an inherently parallel operation, but can benefit from superscalar execution and memory prefetching. In this superscalable case, execution switches to serial mode (e.g., if multiple chains are found in a parallel stage, then these chains are implicitly parallelized).

[0180] Because the input key values ​​are unpredictable, so are the buckets read, and, for large hash tables that reside primarily in main memory, the latency of reading random data is high. To hide this latency, operations including lookups are explicitly pipelined.

[0181] Figure 6 is a flow chart depicting an example parallel process for accelerating detection and / or construction, the process requiring the following steps 601-605. Figure 1 Let's discuss Figure 6 . Used to implement Figure 6 The pseudo code for this process is presented later in this article.

[0182] The detection phase or the construction phase can have a multi-stage processing pipeline so that each stage processes different corresponding data strides in different ways. In an embodiment, steps 601-603 pre-fetch data for the next stride, while steps 604-605 analyze the data of the current stride such as below. In an embodiment, some or all of steps 601-605 can be extended by using SIMD instructions to process multiple objects of the same kind concurrently (such as building key values, hash codes, or bucket addresses).

[0183] For illustration, steps 601-605 are discussed without reference to strides and prefetches. Step 601 reads the join key values ​​by transferring them from main memory onto a call stack or operand stack or into a CPU register. Step 602 converts the join key values ​​into bucket addresses. Step 603 retrieves the buckets or the corresponding first segments of the buckets by transferring them from main memory onto a call stack or operand stack or into a CPU register.

[0184] Step 604 concurrently searches for matches in the buckets. For example, the same or different join key values ​​or hash codes may be concurrently compared to entries in multiple buckets (such as all buckets or bucket segments in the same table segment of a hash table). Step 605 concurrently follows bucket segment chains for different buckets. For example, the corresponding second bucket segments of a separate bucket may be concurrently checked, and subsequent bucket segments may be iteratively and concurrently checked.

[0185] Explicit pipelining means that steps 601-603 "lead" 604-605 by an amount of strides determined by the characteristics of the CPU and memory system, and a buffer in fast local memory connects them. Also, as explained earlier, steps 601-603 are parallel across buckets, while step 4 is parallel within a bucket (but can be over-scaled), and step 605 is serial (but can be over-scaled).

[0186] The main result of the improved design is a very high join lookup rate achieved during the build phase and / or the probe phase, which minimizes the time required to perform the join.

[0187] 9.1 Pseudocode of the detection operation

[0188] Although the construction phase occurs before the detection phase for hash joins, pseudo code for the detection phase is presented here before the pseudo code for the construction phase because the detection phase may be less complex than the construction phase in some embodiments. The following pseudo code may implement the detection phase of a hash join.

[0189]

[0190]

[0191] 9.2 Pseudocode for Build Operation The following pseudocode can implement the build phase of a hash join.

[0192]

[0193]

[0194]

[0195] 10.0 Example Data Mapping Selection

[0196] The hash join using the hash table as discussed extensively above in this paper is just a way to realize relational join.Other ways of executing join can use associated data structure, such as data mapping that is not a hash table and does not use hash.Therefore, the same join can have various alternative implementations based on various alternative data mappings.Every kind of available data mapping can be specially used to optimize or otherwise handle specific problems, such as: join key value data type and / or size, possibility and / or processing, memory requirement and speed of duplicate items.For example, the query plan optimizer can dynamically select the data mapping of a specific type to realize the join based on various concerns and conditions, as discussed later in this paper.

[0197] Figure 7 7 is a block diagram depicting an example computer 700 in an embodiment. Computer 700 joins data rows 710 and 730 based on an optimized selection of one of a plurality of types of data mappings. Computer 700 may be at least one rack-mounted server such as a blade, a personal computer, a mainframe, a virtual computer, or other computing device. When computer 700 includes a plurality of computers, the computers are interconnected via a communication network. Computer 700 may be an embodiment of computer 100.

[0198] Request 750 may specify or otherwise invoke a relational join between data rows 710 and 730. In an embodiment, the execution of the join may rely on (one or more) data structures used to make a match of build data row 710 to probe data row 730. Herein, various kinds of data mappings such as 761-762 are used for such making of the match.

[0199] The types of data mappings 761-762 may be implemented with logic and metadata that may operate as templates, classes, prototypes, or abstract data types (ADTs) from which (one or more) instances may be generated. The types of data mappings 761-762 may be implemented in different ways and executed in different ways. For example, the various types of data mappings may be optimized in various corresponding ways for various corresponding concerns or resources, such as initialization latency, modification latency, read latency, static or heap memory requirements, and / or call and operand stack requirements.

[0200] Various kinds of data mappings may be optimized in various corresponding ways to achieve various corresponding accelerations, such as hardware caching, data parallelization, inelastic horizontal scaling (such as using a multi-core central processing unit (CPU)), elastic horizontal scaling, pipeline parallelization, and / or co-processing (such as through a graphics processing unit (GPU)). Various kinds of data mappings may be optimized in various corresponding ways for various corresponding use cases and / or deviations (such as data skew), database table scans (such as for online analytical processing (OLAP)), and / or random access (such as for online transaction processing (OLTP)). Various kinds of data mappings may be optimized in various corresponding ways for various corresponding integration scenarios, such as decomposition into smaller components (such as portions of compiled query operators) and / or fusion of partial or entire query operators.

[0201] Various kinds of data mappings may be optimized in various corresponding ways for various corresponding aspects of a request such as request 750, such as database schema details, such as aspects of table columns (such as data types, value ranges), data constraints (such as referential integrity and uniqueness). Various kinds of data mappings may be optimized in various corresponding ways for various corresponding database optimizations, such as database indexes, buffers and caches of database blocks, data compression and encoding, and / or in-memory compression units (IMCUs).

[0202] Thus, which of the multiple types of data mappings 761-762 the computer 700 should use to execute the request 750 may depend on static conditions, such as hardware and software deployment and database configuration and schema. The selection of the type of data mapping may also or instead depend on dynamic conditions, such as the details of the request 750, the contents of the data rows 710 and / or 730, cache contents, and / or hardware workload. In any case, the computer 700 compares the static and dynamic conditions with the strengths and weaknesses of the various types of data mappings 761-762 to select a particular type of data mapping 761 that is optimized for the current context or scenario.

[0203] After selecting the type of data mapping 761, computer 700 generates instance 770, which is an instance of the type of data mapping 761. Instance 770 is initially an empty data mapping. Multiple instances of the same type of data mapping 761 (such as instance 170) can be distinguished from each other by context, configuration and / or content. For example, two identical or different queries (such as request 750) can be executed with corresponding instances of the same or different corresponding types of data mappings.

[0204] In this example, build data row 710 is used to populate instance 770. Instance 770 and probe data row 730 are used to make a match to perform the join. The join result is incorporated in whole or in part into response 780 that answers request 750 or is otherwise used to generate the response 780. For example, the type 761 of data mapping can be a hash table variant (such as presented earlier in this article) and can be operated as presented earlier in this article. Various types of data mapping will be presented later in this article, some of which are hash table variants.

[0205] As used herein, a type of data mapping may or may not correspond to a programming language idiom such as a class, template, or prototype. In this article, the distinguishing feature between types of data mapping is that once fully or partially filled, an instance of a type of data mapping should not become an instance of a different type of data mapping. For example, an instance does not support subtype migration, such as to switch between different types of data mappings.

[0206] For example, when two different kinds of data mappings are variants sharing the same implementation class, the two kinds may be distinguished by initial configuration (such as by template parameters or constructor parameters), and the values ​​initially given for these parameters do not change during the life of the respective instances of these kinds. For example, the only difference between two variants of a hash table may be a Boolean parameter indicating something mundane (such as whether the hash table will or will not occasionally rehash). If, for respective two instances of the two variants, the DBMS initially and statically assigns opposite Boolean values ​​to the initialization parameters and never subsequently switches the assignments for any instance, then the methods herein may treat the two variants as independent kinds of data mappings from which multiple instances may be generated.

[0207] 11.0 Example Build Process

[0208] Figure 8 is a flowchart depicting an example process of a computer 700 that dynamically selects one of a plurality of categories of data mappings to perform a relational join. Figure 7 discuss Figure 8 .

[0209] Step 802 receives a request 750 that specifies or implies a relational join of data rows 710 and 730. For example, request 750 may be a CRUD command, such as a DML statement, such as SQL with ODBC.

[0210] Step 804 selects a particular kind of data mapping 761 from a plurality of kinds of data mappings 761-762 that can implement a relational join. For example, step 804 may involve comparing the static and dynamic conditions as discussed above with the advantages and disadvantages of the various kinds of data mappings 761-762 to select a particular kind of data mapping 761 that is optimized for a situation or scenario. Selection criteria and concerns are discussed later in this document.

[0211] Based on the build data row 710, step 806 creates and populates a data map instance 770 of the selected category of data map 761. For example, step 806 may require a build phase as discussed earlier herein. When step 806 is complete, the data map instance 770 is ready for making matches.

[0212] Depending on the embodiment and scenario, data rows 710 and 730 may differ in semantics, format, and / or content, but may still be somewhat interchangeable for respective data sets used for joining. In an embodiment, computer 100 may decide which of the two data sets to use for step 806, and the other data set to use for step 808.

[0213] Step 808 sends a response 780 that answers the request 750 based on the probe data row 730 and the populated data map instance 770. For example, step 808 may require a probe phase for making a match, as discussed earlier herein. For example, the join result may be a final result or an intermediate result of an internal consumption of further executing the request 750 before step 808 sends the response 780.

[0214] 12.0 Example Configuration Concerns

[0215] In presenting Fig. 9 Previously, the following configurability discussion demonstrated that data structures and formats can be used to design robust and performant kinds of data mappings. Figure 7 , Tables 6-8 below list various design and implementation options that may differ between different types of data mappings. When selecting the best type of data mapping for a given situation, scenario, or condition, the computer 700 may analyze, balance, and match these implementation options to various types of data mappings.

[0216] In some cases, a particular enumeration option may exclude some types of data mappings during selection of the optimal type of data mapping. In other cases, a particular enumeration option may cause some types of data mappings (such as types of hash tables) to be favored to some extent when selecting the type of data mapping is cost-based or cost-weighted. For example, retaining duplicate build key values ​​may exclude types of hash tables whose buckets do not extend and / or types of hash tables that support the use of bucket segmentation.

[0217] In some cases, a particular enumeration option may cause different instances of the same kind of data mapping 761 (including instance 770) to be configured differently. In some cases, the same enumeration option may cause instances of the kind of data mapping to be specifically configured when one kind of data mapping is selected, while no instance configuration may be required when a different kind of data mapping is selected instead. For example, some kinds of data mapping may be more configurable than other kinds of data mapping, while other kinds of data mapping may accommodate a wider range of scenarios without instance configuration.

[0218] In some cases, this flexibility can also affect which data mapping is chosen. For example, one category of hash tables may include a general-purpose hash function, while another category of hash tables may be excluded unless an application-specific hash function is provided for each instance. Likewise, another category of hash tables may be excluded unless the application-specific hash function provides perfect hashing, such that different join key values ​​always result in different hash codes, and collisions of different key values ​​are impossible.

[0219] In the previous Tables 2-5, the additional listed options presented earlier in this document may also affect the selection of a data mapping and / or instance configuration of a category. Table 6 below lists example configuration concerns 931-934, some or all of which may be incorporated into the data mapping of (one or more) categories in various embodiments.

[0220]

[0221] Configuration concerns 931-934 are generally presented as follows. Specific implementation options for configuration concerns 931-934 will be presented later in this document.

[0222] The width of the build key is a configuration concern 931. For example, whether a hash function should be applied to the build key value and whether the data map should store the build key value directly or a hash code may depend on the build key size (such as when the build key may be text).

[0223] Configuration concerns 932 depend on whether the data map should retain additional data such as non-key fields that construct data row 710, and whether the data map should store the additional data directly or instead store pointers or array offsets for indirect access to the additional data.

[0224] Configuration concerns 933 depend on whether duplicate construction keys are possible and / or important. For example, detecting and / or preserving duplicates may incur time and / or space costs and / or structural complexity.

[0225] As discussed above and below in this paper, data mapping can be a hash table containing buckets and / or bucket segments. Even when selecting data mapping kind and / or configuration instance 770 depends on other concerns or scenarios, configuration concerns 934 also provides fixed size for buckets or segments. For example, even if multiple instances (including instance 770) of data mapping 761 of the same kind have different corresponding construction keys or hash code sizes, the kinds of data mapping 761 can also have the same fixed bucket segment size. As discussed later in this paper, the different sizes or included data to be stored in the construction key entry may make the data mapping of different corresponding kinds selected for use.

[0226] 13.0 Example Bucket Arrangement

[0227] Different kinds of hash tables can have different bucket arrangements. In fact, some kinds of hash tables have no buckets, which is the same as storing only one key entry per bucket by design, such as for cuckoo hashing, which is different from storing only one key entry per bucket segment.

[0228] In an embodiment, a bucket contains a segment array that can dynamically acquire additional segments to provide a bucket with more or less unlimited capacity to store build key entries. For example, duplicate build key values ​​and / or conflicts mapping multiple different build key values ​​to the same bucket may increase the demand on bucket capacity.

[0229] As explained earlier in this document, bucket segments can be pre-allocated in a pool, retrieved from the pool on demand, and released back to the pool when the instance 770 is discarded. In an embodiment, different instances of the same or different kinds of data mappings share the same pool of spare segments. Retrieving from the pool and then returning to the pool is a logical transition that does not require the physical movement of the segments.

[0230] In other words, whether in use or not, the segments physically remain stored in the same corresponding positions of the array of segments operated as a pool. In an embodiment, each segment in the pool can be identified based on the memory address or array offset of the segment. The address or offset can operate as a pointer to the segment, such as when the segment appears in a linked list of segments (such as a segment array for a bucket). For example, a segment can contain a pointer to the next and / or previous segment in the linked list.

[0231] 14.0 Example Bucket Contents

[0232] Table 7 below lists example bucket contents 941 - 943 for pipeline parallelization for increased throughput, some or all of which may be incorporated into the data map(s) of the type in various embodiments.

[0233] Bucket Contents meaning 941 Do not store key values 942 Variable-size key values 943 Hash code of the key value

[0234] Bucket contents 941 do not include storing key values ​​in the bucket, such as in cases where a) hash collisions are not possible, such as for a perfect hash, or b) the key value is too large to be stored directly in the bucket. For example, literal key values ​​and compound key values ​​do not need to be stored directly in the bucket, and the bucket may store address pointers or array offsets to these data instead.

[0235] For example, a pointer can provide indirect access to a variable length text key value, which can even be a character large object (CLOB). Other fixed size agents for variable size keys include hash codes and encoding dictionary codes. For example, bucket contents 943 store hash codes in buckets.

[0236] When the variable-sized key value has a very limited size, such as a Unicode character or a short text such as a stock ticker symbol, then bucket content 942 stores the key value directly inline in the bucket. Depending on the embodiment, the variable-sized short text inline in the bucket may be null-terminated, whitespace-padded to a fixed size, or accompanied by a quick size indicator such as a character count.

[0237] 15.0 Bucket Chaining and Pooling

[0238] As discussed earlier herein, bucket segments can have multi-byte aligned addresses. Because a physical segment can be an array of bucket segments, a physical segment can have the same address and alignment as the first bucket segment in the array. Also as discussed earlier herein, multi-byte aligned pointers have the least significant bits that are always zero, implicit, not stored, and / or reused as bit field(s). Therefore, pointers to bucket segments can be truncated.

[0239] The lock status is stored as a bit in the low bit of the bucket segment pointer, and bucket segments of the same bucket are daisy-chained into a linked list. For example, Figure 4 Bucket segments 440 and 423 are shown linked together by a bucket segment pointer NEXT.

[0240] Although bucket segment pointer NEXT points to bucket segment 423, bucket segment pointer NEXT is stored in bucket segment 440, as shown. The lock bit in NEXT indicates whether overflow bucket segment 423 is locked or unlocked. Similarly, for another bucket, overflow bucket segments 421-422 are linked as shown by the bucket segment pointer, which contains a lock bit indicating whether overflow bucket segment 422 is locked or unlocked. For example, the same or different computing threads can have multiple overflow bucket segments locked for the same or different buckets, but different buckets should not share the same bucket segment.

[0241] In an embodiment, base pointers 0-3 have pointer bit fields similar to the pointer bit fields of bucket segment pointers. For example, the lock bit of base pointer 1 indicates whether table segment 430 (and all its buckets) is locked or unlocked. In an embodiment, table segment 430 has a bitmap containing multiple corresponding lock bits for the buckets of table segment 430. Another bit in the low bits of the bucket segment pointer records whether the overflow bucket segment pointed to has been initialized, which facilitates threading of initialization work.

[0242] In an embodiment, overflow bucket segmentation 410 itself is a segment array, which includes multiple pool segments as shown in the figure. Each pool segmentation includes an array of overflow bucket segments, as shown in the figure. For example, overflow bucket segments 422-423 are in the same pool segmentation, but overflow bucket segmentation 421 is in a different pool segmentation. Buckets can include multiple overflow bucket segments in the same or different pool segments. For example, overflow bucket segments 421-422 are part of the same bucket, but in different pool segments. Similarly, overflow bucket segments 422-423 are in the same pool segmentation, but in different buckets.

[0243] Bucket segments may fit into a hardware cache line. In an embodiment, table segments and / or pool segments may be physical segments. A fixed-size physical segment may contain multiple fixed-size bucket segments. In an embodiment, table segments and pool segments have different corresponding fixed capacities, as shown.

[0244] Even though a fixed size for a physical segment may be the most efficient allocation size for a particular computer and operating system (OS), obtaining a new physical segment may require high latency memory allocation. Bucket segments may be allocated from physical segments and with low latency. For example, a physical segment may be operated as a small pool of bucket segments. Likewise, there may be a pool of physical segments, which may be a pool of pools, such as the overflow bucket segment 410 shown containing two pool segments, each of which is itself a small pool of bucket segments.

[0245] As discussed earlier in this document, bucket segments can have multi-byte aligned addresses. Because a physical segment can be an array of bucket segments, a physical segment can have the same address and alignment as the first bucket segment in the array. And as discussed earlier in this document, a multi-byte aligned pointer has the least significant bits that are always: zero, implicit, not stored and / or reused as (one or more) bit fields. Therefore, a pointer to a bucket segment can be a truncated pointer to a physical segment, whose unused bits include an integer bit field containing at least an array offset of the bucket segment within the physical segment, and there may still be unused bits for other bit fields. In an embodiment, the array offset bit field is additionally or alternatively included in the hash code of the key entry belonging to the bucket segment.

[0246] 16.0 Second Exemplary Embodiment

[0247] Fig. 9 is a flow chart depicting an example process of a computer to dynamically select one of multiple categories of data mappings to perform a relational join. Fig. 9 The following discussion of describes an exemplary embodiment showing implementation options that can be used with some or all of the embodiments presented previously herein. Features of this exemplary embodiment are not requirements of the embodiments presented previously herein.

[0248] Fig. 9 The steps shown in are different corresponding ways of selecting a data mapping of one of multiple categories of data mappings for performing relational joins. In the illustrated embodiment, these steps occur sequentially to gradually eliminate various categories of data mappings until one or a few categories are left for final selection. In other embodiments, some or all of these steps are combined into a single step.

[0249] Various kinds of data mappings may be optimized in various corresponding ways for various corresponding use cases and / or deviations (such as data skew), database table scans (such as for online analytical processing (OLAP)), and / or random access (such as for online transaction processing (OLTP)). As observed earlier in this document, accurately predicting join selectivity and building table cardinality may be difficult or impossible, which may be a key factor in estimating the data distribution of a data mapping as a preface to establishing the initial capacity and configuration of the data mapping.

[0250] Step 902 selects the type of data mapping without considering the join selectivity or cardinality of the constructed data rows. For example, step 902 may exclude types of data mapping that are not suitable when the selectivity and / or cardinality are unknown. Thus, step 902 allows for missing or stale data statistics.

[0251] Step 904 selects a type of data mapping that can facilitate matching dictionary-encoded join keys without decoding the join keys. For example, the join key can be a dictionary code, which can also be used as an offset to an array. For example, step 904 can select a type of data mapping based on (one or more) arrays.

[0252] In this exemplary embodiment, in addition to various types of hash tables, the types of data mapping may also include array tables. Hash tables are usually indexed by hash codes of join keys. Array tables are indexed by encoded dictionary codes of join keys.

[0253] 16.1 Dimensions and alignment

[0254] Prior to presenting step 906, the size and alignment of the buckets or bucket segments may be integrated into various types of data maps, as described below and with reference to Figure 4 , as discussed earlier in this document. Various kinds of data maps may contain segmented buckets as discussed earlier in this document. This exemplary embodiment has a multi-threaded build phase, where each compute thread may temporarily and individually lock a bucket segment to prevent interference from other threads. For example, the bucket API may have subroutines to navigate segmented buckets and lock and unlock individual bucket segments. A thread should: add a build key entry to a bucket segment only after locking the bucket segment, and unlock the bucket segment immediately thereafter.

[0255] This exemplary embodiment supports the following three hash tables:

[0256] KDZK_KV_GENERIC: The key itself is not stored in the bucket, but rather a portion of its hash value is stored. Therefore lookups are not exact, but are usually close to exact due to the large number of hash bits used. This mode is useful when the key is complex and / or large, and the client is able to post-process the results to ensure an exact match. Duplicate keys are allowed.

[0257] KDZK_KV_GD: In this mode, the key value is always 4 bytes and is assumed to be non-zero, and the key value can be an encoding dictionary code. The key value is stored in the KV table 400, so the lookup is exact. The lookup still requires the hash value. Duplicate key values ​​are allowed.

[0258] KDZK_KV_DIRECT: In this mode, the supplied key value is stored in the KV table 400 as the length plus the bytes of the key value. Therefore, the length of the key value can be different. The lookup is exact, but the lookup still requires the hash value. Duplicate key values ​​are allowed.

[0259] Now return to Fig. 9 , step 906 selects one of at least three hash tables (such as KDZK_KV_GENERIC, KDZK_KV_GD, and KDZK_KV_DIRECT).

[0260] As explained above, a bucket or bucket segmentation may include an array of bucket segmentation pointers and key entries. In various examples, a key entry may include various components, such as a key value and / or another value that may have various sizes. In various examples, a 64-byte bucket or bucket segmentation may be configured for various combinations of various components of various sizes.

[0261] Various examples may have various fixed-size build keys, such as for numeric or string values. For example, a day key may be a two-byte integer. A month name key may have ten bytes, including: a) one byte indicating the string length as a number of characters and a maximum of nine characters, or b) ten characters including space padding as needed.

[0262] Table 8 below lists the predefined configurations of buckets or bucket segments, each of which has a separate data map. Size and alignment are in bytes. Because the size of a bucket segment pointer depends on whether the bucket segment pointer is implemented as a pointer or an offset as explained earlier in this document, the implementation of the bucket segment pointer can affect the capacity of a bucket or bucket segment to store key values ​​and / or other values.

[0263]

[0264] Bucket configurations 1145-1146 and 1149 store key values ​​in buckets but do not store other values. Each of bucket configurations 1141-1152 can be used to configure a separate corresponding type of data mapping, such as a hash table. According to the key size, bucket configurations 1141-1152 provide five types of data mappings, which have five corresponding key sizes of 2, 4, 6, 8 and 10 bytes. According to the value size, bucket configurations 1141-1152 provide three types of data mappings, which have 4 or 8 bytes or three corresponding value sizes or do not store values. Through bucket alignment, bucket configurations 1141-1152 provide three types of data mappings, with three corresponding alignments of 2, 4 and 8 bytes respectively. Individually, bucket configurations 1141-1152 are twelve different types of data mappings.

[0265] Depending on the embodiment, each key entry contains a reference, which is either an array offset or a pointer, which are shown in the above table as an index-offset method and a memory pointer method, respectively, which are mutually exclusive embodiments for a given hash table. By the amount of key entries per bucket segment and the offset of the physical segment as a bucket segment pointer, the bucket configurations 1141-1152 provide seven kinds of data mappings, which have 3, 4, 5, 6, 7, 10, and 15 key entries. By the amount of key entries per bucket segment with an address pointer as a bucket segment pointer, the bucket configurations 1141-1152 provide six kinds of data mappings, which have six corresponding bucket segment capacities of 3, 4, 5, 6, 9, and 13 key entries.

[0266] The resizing of the KV table 400, such as for overflow or rebalancing, is as follows. To increase the capacity of the KV table 400, the segment index field is increased by extending it by n bits, which increases the number of segments of the hash table by 2. n times or more.

[0267] Entries in an existing bucket are split into 2 n This resizing scheme minimizes contention, so while one segment is being resized, other segments are not blocked for inserts, so resizing and inserts can be done in parallel.

[0268] 17.0 Database Overview

[0269] Embodiments of the present invention are used in the context of a database management system (DBMS).Therefore, a description of an example DBMS is provided.

[0270] Generally speaking, a server such as a database server is a combination of integrated software components and an allocation of computing resources such as memory, nodes, and processes on the nodes for executing the integrated software components, where the combination of software and computing resources is dedicated to providing a specific type of functionality on behalf of the server's clients. A database server controls and facilitates access to a specific database, processing client requests to access the database.

[0271] A user interacts with the database server of a DBMS by submitting commands to the database server that cause the database server to perform operations on the data stored in the database. A user may be one or more applications running on a client computer that interacts with the database server. Multiple users may also be collectively referred to as users in this article.

[0272] A database includes data and a database dictionary, which is stored on a persistent storage mechanism such as a collection of hard disks. A database is defined by its own separate database dictionary. The database dictionary includes metadata that defines the database objects contained in the database. In practice, the database dictionary defines many databases. Database objects include tables, table columns, and tablespaces. A tablespace is a collection of one or more files used to store data for various types of database objects, such as tables. If the data for a database object is stored in a tablespace, then the database dictionary maps the database object to one or more tablespaces that hold the data for the database object.

[0273] The DBMS consults the database dictionary to determine how to execute database commands submitted to the DBMS. Database commands can access database objects defined by the dictionary.

[0274] Database commands can be in the form of database statements. In order for a database server to process database statements, the database statements must conform to the database language supported by the database server. A non-limiting example of a database language supported by many database servers is SQL, including proprietary forms of SQL supported by database servers such as Oracle (such as, Oracle Database 11g). SQL data definition language ("DDL") instructions are issued to a database server to create or configure database objects, such as tables, views, or complex types. Data manipulation language ("DML") instructions are issued to a DBMS to manage data stored in a database structure. For example, SELECT, INSERT, UPDATE, and DELETE are common DML instruction examples in some SQL implementations. SQL / XML is a common extension of SQL used when manipulating XML data in an object-relational database.

[0275] A multi-node database management system consists of interconnected nodes that share access to the same database. Typically, the nodes are interconnected via a network and share, to varying degrees, access to shared storage, such as a set of disk drives and data blocks stored thereon. The nodes in a multi-node database system may be in the form of a group of computers (such as workstations and / or personal computers) interconnected via a network. Alternatively, the nodes may be nodes of a grid consisting of nodes in the form of server blades interconnected to other server blades on a rack.

[0276] Each node in a multi-node database system hosts a database server. A server, such as a database server, is a combination of integrated software components and an allocation of computing resources, such as memory, nodes, and processes on the nodes for executing the integrated software components on processors, that are dedicated to performing specific functions on behalf of one or more clients.

[0277] Resources from multiple nodes in a multi-node database system can be allocated to run the software of a particular database server. Each combination of software and allocation of resources among nodes is a server referred to herein as a "server instance" or "instance." A database server can include multiple database instances, some or all of which run on separate computers (including separate server blades).

[0278] 17.1 Query Processing

[0279] A query is an expression, command, or set of commands that, when executed, causes a server to perform one or more operations on a data set. A query may specify source data objects (one or more), such as tables (one or more), columns (one or more), views (one or more), or snapshots (one or more), from which result sets (one or more) are to be determined. For example, source data objects (one or more) may appear in the FROM clause of a structured query language ("SQL") query. SQL is a well-known example language for querying database objects. As used herein, the term "query" is used to refer to any form of representation of a query, including queries in the form of database statements and any data structure used for internal query representation. The term "table" refers to any source object that is referenced or defined by a query and represents a collection of rows, such as a database table, a view, or an inline query block (such as an inline view or subquery).

[0280] Queries can perform operations on data from source data objects row by row as the object(s) are loaded, or on the entire source data object(s) after the object(s) have been loaded. Result sets generated by some operations can make available to other operations(s), and in this way, result sets can be filtered out or narrowed based on certain criteria, and / or joined or combined with other result sets(s) and / or other source data objects(s).

[0281] A subquery is a portion or component of a query that is distinct from the other portion(s) or component(s) of the query and can be evaluated separately from the other portion(s) or component(s) of the query (i.e., as a separate query). The other portion(s) or component(s) of the query can form an outer query, which may or may not include other subqueries. A subquery nested within an outer query can be evaluated separately one or more times, while computing results for the outer query.

[0282] Generally speaking, a query parser receives a query statement and generates an internal query representation of the query statement. Typically, the internal query representation is a collection of interconnected data structures that represent various components and structures of the query statement.

[0283] The internal query representation may be in the form of a node graph, with each interconnected data structure corresponding to a node and a component of the represented query statement. The internal representation is typically generated in memory for evaluation, manipulation, and transformation.

[0284] Hardware Overview

[0285] According to one embodiment, the technology described herein is implemented by one or more special-purpose computing devices. The special-purpose computing device can be hard-wired to perform these technologies, or can include digital electronic devices (such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are permanently programmed to perform these technologies), or can include one or more general-purpose hardware processors that are programmed to perform these technologies according to program instructions in firmware, memory, other storage devices, or combinations. Such special-purpose computing devices can also combine customized hard-wired logic, ASICs, or FPGAs with customized programming to implement these technologies. The special-purpose computing device can be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that combines hard-wiring and / or program logic to implement these technologies.

[0286] For example, Fig.101 is a block diagram illustrating a computer system 1000 upon which embodiments of the present invention may be implemented. Computer system 1000 includes a bus 1002 or other communication mechanism for communicating information, and a hardware processor 1004 coupled to bus 1002 for processing information. Hardware processor 1004 may be, for example, a general purpose microprocessor.

[0287] The computer system 1000 also includes a main memory 1006, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 1002 for storing information and instructions to be executed by the processor 1004. The main memory 1006 may also be used to store temporary variables or other intermediate information during the execution of instructions executed by the processor 1004. These instructions, when stored in a non-transitory storage medium accessible to the processor 1004, make the computer system 1000 a special-purpose machine customized to perform the operations specified in the instructions.

[0288] Computer system 1000 also includes a read only memory (ROM) 1008 or other static storage device coupled to bus 1002 for storing static information and instructions for processor 1004. A storage device 1010, such as a magnetic disk, optical disk, or solid state drive, is provided and coupled to bus 1002 for storing information and instructions.

[0289] The computer system 1000 may be coupled to a display 1012, such as a cathode ray tube (CRT), via the bus 1002 for displaying information to a computer user. An input device 1014, including alphanumeric and other keys, is coupled to the bus 1002 for communicating information and command selections to the processor 1004. Another type of user input device is a cursor control 1016, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 1004 and for controlling cursor movement on the display 1012. Such input devices typically have two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify a position in a plane.

[0290] Computer system 1000 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that is combined with a computer system to make or program computer system 1000 into a special purpose machine. According to one embodiment, computer system 1000 performs the techniques described herein in response to processor 1004 executing one or more sequences of one or more instructions contained in main memory 1006. These instructions may be read into main memory 1006 from another storage medium, such as storage device 1010. Execution of the sequences of instructions contained in main memory 1006 causes processor 1004 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0291] The term "storage medium" as used herein refers to any non-transient medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical disks, magnetic disks, or solid-state drives, such as storage device 1010. Volatile media include dynamic memory, such as main memory 1006. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a pattern of holes, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips, or cassette tapes.

[0292] Storage media are distinct from but can be used in conjunction with transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that comprise bus 1002. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0293] Various forms of media may be involved in carrying one or more sequences of one or more instructions to the processor 1004 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 1000 may receive the data over the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal and appropriate circuitry may place the data on the bus 1002. The bus 1002 transfers the data to the main memory 1006, from which the processor 1004 retrieves and executes the instructions. The instructions received by the main memory 1006 may optionally be stored on the storage device 1010 before or after execution by the processor 1004.

[0294] The computer system 1000 also includes a communication interface 1018 coupled to the bus 1002. The communication interface 1018 provides a two-way data communication coupled to a network link 1020, wherein the network link 1020 is connected to a local network 1022. For example, the communication interface 1018 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection with a corresponding type of telephone line. As another example, the communication interface 1018 can be a local area network (LAN) card to provide a data communication connection with a compatible LAN. A wireless link can also be implemented. In any such implementation, the communication interface 1018 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0295] The network link 1020 typically provides data communication to other data devices through one or more networks. For example, the network link 1020 can provide a connection to a host computer 1024 or to data equipment operated by an Internet Service Provider (ISP) 1026 through a local network 1022. The ISP 1026 in turn provides data communication services through a global packet data communication network, now commonly referred to as the "Internet" 1028. Both the local network 1022 and the Internet 1028 use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 1020 and through the communication interface 1018, which carry the digital data to and from the computer system 1000, are example forms of transmission media.

[0296] Computer system 1000 can send messages and receive data (including program code) through the network(s), network link 1020, and communication interface 1018. In the Internet example, server 1030 can send the requested code for an application program through Internet 1028, ISP 1026, local network 1022, and communication interface 1018.

[0297] The received code may be executed by processor 1004 as it is received, and / or stored in storage device 1010 or other non-volatile storage for later execution.

[0298] Software Overview

[0299] Fig.11 1 is a block diagram of a basic software system 1100 that may be used to control the operation of the computing system 1000. The software system 1100 and its components (including their connections, relationships, and functions) are merely exemplary and are not meant to limit implementation of the example embodiment(s). Other software systems suitable for implementing the example embodiment(s) may have different components, including components with different connections, relationships, and functions.

[0300] The software system 1100 is provided for directing the operation of the computing system 1000. The software system 1100, which may be stored on system memory (RAM) 1006 and fixed storage (eg, hard disk or flash memory) 1010, includes a kernel or operating system (OS) 1110.

[0301] The OS 1110 manages low-level aspects of computer operation, including managing the execution of processes, memory allocation, file input and output (I / O), and device I / O. One or more application programs, represented as 1102A, 1102B, 1102C ... 1102N, may be "loaded" (e.g., transferred from fixed storage 1010 into memory 1006) for execution by the system 1100. Applications or other software intended for use on the computer system 1000 may also be stored as a downloadable set of computer-executable instructions for downloading and installation, for example, from an Internet location (e.g., a Web server, app store, or other online service).

[0302] The software system 1100 includes a graphical user interface (GUI) 1115 for receiving user commands and data in a graphical (e.g., "click" or "touch gesture") manner. In turn, these inputs can be operated by the system 1100 according to instructions from the operating system 1110 and / or (one or more) applications 1102. The GUI 1115 is also used to display the results of the operations from the OS 1110 and (one or more) applications 1102, based on which the user can provide additional input or terminate the session (e.g., log off).

[0303] The OS 1110 may execute directly on the bare hardware 1120 (e.g., processor(s) 1004) of the computer system 1000. Alternatively, a hypervisor or virtual machine monitor (VMM) 1130 may be inserted between the bare hardware 1120 and the OS 1110. In this configuration, the VMM 1130 acts as a software "buffer" or virtualization layer between the OS 1110 and the bare hardware 1120 of the computer system 1000.

[0304] VMM 1130 instantiates and runs one or more virtual machine instances ("guests"). Each guest includes a "guest" operating system (such as OS 1110), and one or more applications (such as (one or more) applications 1102) designed to execute on the guest operating system. VMM 1130 presents a virtual operating platform to the guest operating system and manages the execution of the guest operating system.

[0305] In some cases, the VMM 1130 can allow a guest operating system to run as if it were running directly on the bare hardware 1120 of the computer system 1100. In these cases, the same version of the guest operating system that is configured to execute directly on the bare hardware 1120 can also execute on the VMM 1130 without modification or reconfiguration. In other words, the VMM 1130 can provide full hardware and CPU virtualization to the guest operating system in some cases.

[0306] In other cases, the guest operating system may be specially designed or configured to execute on the VMM 1130 to improve efficiency. In these cases, the guest operating system is "aware" that it is executing on the virtual machine monitor. In other words, the VMM 1130 may provide paravirtualization to the guest operating system in some cases.

[0307] A computer system process includes an allocation of hardware processor time, as well as an allocation of memory (physical and / or virtual), an allocation of memory being used to store instructions executed by the hardware processor, for storing data generated by the execution of instructions by the hardware processor, and / or for storing hardware processor state (e.g., contents of registers) between allocations of hardware processor time when the computer system process is not running. A computer system process runs under the control of an operating system and may run under the control of other programs executing on the computer system.

[0308] cloud computing

[0309] The term "cloud computing" is used generally herein to describe a computing model that enables on-demand access to a shared pool of computing resources (such as computer networks, servers, software applications, and services) and which allows resources to be quickly provisioned and released with minimal management effort or service provider interaction.

[0310] A cloud computing environment (sometimes referred to as a cloud environment or just a cloud) can be implemented in a variety of different ways to best suit different requirements. For example, in a public cloud environment, the underlying computing infrastructure is owned by an organization that makes its cloud services available to other organizations or the public. In contrast, a private cloud environment is generally intended for use by or within a single organization. A community cloud is intended to be shared by several organizations within a community; while a hybrid cloud includes two or more types of clouds (e.g., private, community, or public) bound together by data and application portability.

[0311] In general, the cloud computing model enables some of those responsibilities that might previously have been provided by an organization's own information technology department to instead be delivered as a service layer within a cloud environment for use by consumers (either internally or externally to the organization, depending on the public / private nature of the cloud). Depending on the specific implementation, the precise definition of the components or features provided by or within each cloud service layer may vary, but common examples include: Software as a Service (SaaS), in which consumers use software applications running on a cloud infrastructure, while the SaaS provider manages or controls the underlying cloud infrastructure and applications. Platform as a Service (PaaS), in which consumers can use software programming languages ​​and development tools supported by a PaaS provider to develop, deploy, and otherwise control their own applications, while the PaaS provider manages or controls other aspects of the cloud environment (i.e., everything under the runtime execution environment). Infrastructure as a Service (IaaS), in which consumers can deploy and run arbitrary software applications, and / or provide processes, storage, networks, and other basic computing resources, while the IaaS provider manages or controls the underlying physical cloud infrastructure (i.e., everything below the operating system layer). Database as a Service (DBaaS), where the consumer uses a database server or database management system running on a cloud infrastructure, while the DbaaS provider manages or controls the underlying cloud infrastructure and applications.

[0312] The above basic computer hardware and software and cloud computing environment are presented to illustrate the basic underlying computer components that can be used to implement the example embodiment(s). However, the example embodiment(s) are not necessarily limited to any particular computing environment or computing device configuration. Instead, according to the present disclosure, the example embodiment(s) can be implemented in any type of system architecture or processing environment that a person skilled in the art will understand as being capable of supporting the features and functions of the example embodiment(s) presented herein.

[0313] In the foregoing specification, embodiments of the present invention have been described with reference to numerous specific details, which may vary from implementation to implementation. Therefore, the specification and drawings should be viewed in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention and what the applicant intends to be the scope of the invention is the literal and equivalent range of the resulting claims in the specific form of the set of claims issued from this application, including any subsequent corrections.

Claims

1. A method comprising: receiving a request to access a plurality of probe data rows, wherein each data row of the plurality of probe data rows is associated with a corresponding probe key value; selecting a particular bucket from among the plurality of buckets of the hash table that contains entries of the plurality of built key values; concurrently probing the specific bucket to detect whether the plurality of entries of the build key values ​​include an entry of a probe key value for a specific data row of the plurality of probe data rows, wherein the entry of the probe key value for the specific data row includes a value selected from the group consisting of: a probe key value for the specific data row and a hash code of the probe key value for the specific data row; A response to the request to access the plurality of probe data rows is sent, the response being based on the concurrently probing the particular bucket.

2. The method of claim 1, wherein the concurrently probing the particular bucket comprises executing an instruction selected from the group consisting of: Single Instruction Multiple Data (SIMD) instructions to concurrently check a plurality of entries of the entries of the plurality of build keys, a first plurality of instructions, on a superscalar processor, to concurrently compare said entry of the probe key for said particular row of data with corresponding entries of said plurality of build keys, and A second plurality of instructions, on a super-pipelined processor, concurrently compares the entry of the probe key for the particular row of data with corresponding entries of the entries of the plurality of build keys.

3. The method of claim 1, wherein each of the plurality of buckets is configured according to at least one item selected from the group consisting of: The bucket and a corresponding hardware cache line in the first plurality of hardware cache lines have the same memory address alignment, and The bucket has a first size that is no larger than a second size of a corresponding hardware cache line in the second plurality of hardware cache lines.

4. The method of claim 1 , further comprising pre-fetching into a hardware cache at least one item selected from the group consisting of: a subset of the plurality of buckets, probe key values ​​for a first subset of the plurality of probe data rows, and A hash code of the probe key values ​​for a second subset of the plurality of rows of probe data.

5. The method of claim 4, wherein: Multiple items are prefetched concurrently; The plurality of items include at least one item selected from the group consisting of: the subset of the plurality of buckets, the probe key values ​​for a first subset of the plurality of probe data rows, and The hash codes of the probe key values ​​for a second subset of the plurality of probe data rows.

6. The method of claim 4, wherein: the subset of the plurality of buckets includes the particular bucket; a second subset of the plurality of probe data rows not including the particular data row; Prefetching the subset of the plurality of buckets occurs concurrently with at least one item selected from the group consisting of: pre-fetching hash codes of probe key values ​​for a second subset of the plurality of probe data rows, and Probe key values ​​for a first subset of the plurality of probe data rows are pre-fetched. The method of claim 1 , wherein the particular bucket comprises a segmented array.

8. The method of claim 1, further comprising concurrently computing corresponding memory addresses for subsets of the plurality of buckets.

9. The method of claim 8, wherein the concurrently computing the corresponding memory addresses of the subset of the plurality of buckets comprises executing a SIMD instruction that concurrently computes, for each bucket of the subset of the plurality of buckets, a memory address selected from the group consisting of: Buckets, and The segments of the corresponding segment array.

10. The method of claim 1, wherein the probe key value of a specific data row comprises at least one item selected from the group consisting of: a grouping key, a composite candidate key, an encoding dictionary code, and a set of one or more fields of the specific data row that are not candidate keys.

11. A method comprising: receiving a request to access a plurality of build data rows, wherein each data row of the plurality of build data rows is associated with a corresponding build key value; selecting a specific bucket from a plurality of buckets of the hash table, the specific bucket containing a plurality of entries of the constructed key value in corresponding positions within the specific bucket; detecting that the particular bucket does not contain an entry for a build key value for a particular data row of the plurality of build data rows, wherein the entry for the build key value for the particular data row comprises a value selected from the group consisting of: a build key value for the particular data row and a hash code of the build key value for the particular data row; concurrently checking a plurality of locations in the particular bucket to detect an empty location within the particular bucket; storing an entry of the constructed key value of the specific data row in an empty position in the specific bucket; A response to the request to access the plurality of rows of construction data is sent, the response being based on the hash table.

12. The method of claim 11, wherein the concurrently checking multiple locations in the particular bucket to detect empty locations comprises executing an instruction selected from the group consisting of: Single Instruction Multiple Data (SIMD) instructions that concurrently check multiple locations to find an empty location within that particular bucket, A plurality of superscalar instructions concurrently detect whether a corresponding position in the specific bucket is empty, and A plurality of super-pipelined instructions concurrently detect whether a corresponding position in the specific bucket is empty.

13. The method of claim 11, wherein each bucket of the plurality of buckets is configured according to at least one of: The bucket and a corresponding hardware cache line in the first plurality of hardware cache lines have the same memory address alignment, and The bucket has a first size that is no larger than a second size of a corresponding hardware cache line in the second plurality of hardware cache lines.

14. The method of claim 11, further comprising pre-fetching into a hardware cache at least one item selected from the group consisting of: a subset of the plurality of buckets, construction key values ​​for a first subset of the plurality of construction data rows, and The hash codes of the construction key values ​​of a second subset of the plurality of construction data rows.

15. The method of claim 14, wherein: Multiple items are prefetched concurrently; The plurality of items is at least one item selected from the group consisting of: the subset of the plurality of buckets, probe key values ​​for a first subset of the plurality of probe data rows, and The hash codes of the probe key values ​​for a second subset of the plurality of probe data rows.

16. The method of claim 14, wherein: the subset of the plurality of buckets includes the particular bucket; a second subset of the plurality of constructed data rows does not include the particular data row; Prefetching the subset of the plurality of buckets occurs concurrently with at least one item selected from the group consisting of: pre-fetching hash codes of build key values ​​for a second subset of the plurality of build data rows, and Build key values ​​for a first subset of the plurality of build data rows are pre-fetched. The method of claim 11 , wherein the particular bucket comprises a segment array.

18. The method of claim 11, further comprising concurrently computing corresponding memory addresses for subsets of the plurality of buckets.

19. The method of claim 18, wherein the concurrently computing the corresponding memory addresses of the subset of the plurality of buckets comprises executing a SIMD instruction that concurrently computes, for each bucket of the subset of the plurality of buckets, a memory address selected from the group consisting of: Buckets, and The segments of the corresponding segment array.

20. The method of claim 11, wherein the constructed key value of the specific data row includes at least one item selected from the group consisting of: a grouping key, a composite candidate key, an encoding dictionary code, and a set of one or more fields of the specific data row that are not candidate keys.

21. The method of claim 11, further comprising: In the same bucket or different buckets of the plurality of buckets, a plurality of entries of build key values ​​for a subset of the plurality of build data rows are concurrently adjusted.

22. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the method of any one of claims 11-21 to be performed.

23. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the method of any one of claims 1-10 to be performed.

24. A system comprising: processor; as well as A memory coupled to the processor and having executable instructions stored thereon, which, when executed by the processor, cause the processor to perform the method of any one of claims 11-21.

25. A system comprising: processor; as well as A memory coupled to the processor and having executable instructions stored thereon, which, when executed by the processor, cause the processor to perform the method of any one of claims 1-10.

26. A computer program product comprising instructions which, when executed by a processor of a computer, cause the computer to perform the method of any one of claims 11 to 21.

27. A computer program product comprising instructions which, when executed by a processor of a computer, cause the computer to perform the method of any one of claims 1 to 10.

Images