CN115794874A - Method for accelerating GPU operator execution in heterogeneous database system and application - Google Patents
Method for accelerating GPU operator execution in heterogeneous database system and application Download PDFInfo
- Publication number
- CN115794874A CN115794874A CN202211459169.4A CN202211459169A CN115794874A CN 115794874 A CN115794874 A CN 115794874A CN 202211459169 A CN202211459169 A CN 202211459169A CN 115794874 A CN115794874 A CN 115794874A
- Authority
- CN
- China
- Prior art keywords
- operator
- query
- gpu
- execution
- fusion
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The invention discloses a method for accelerating GPU operator execution in a heterogeneous database system, which judges whether a specific operator combination needs to be fused or not in a query optimization stage and executes according to a scheme after query optimization in the query execution stage. The method comprises the following steps: acquiring a query plan generated by a heterogeneous database system based on a traditional database for a query statement; determining whether a special execution plan generation strategy is considered or not according to whether a GPU operator is used or not by the query plan; judging whether fusion is effective or not and deciding whether to place an operator on a GPU or not by considering the fused operator cost for the operators in the specific operator combination through a cost estimation method; after the operators in the specific combination are placed on the GPU, selecting a specific fusion execution strategy; and the heterogeneous database system executes the execution plan according to the fusion execution strategy. The invention also discloses application of the method in accelerating GPU operator execution in a heterogeneous database system.
Description
Technical Field
The invention belongs to the technical field of heterogeneous databases, relates to a GPU operator acceleration technology applied to a heterogeneous database system, and particularly relates to a method for fusing GPU operator execution in a heterogeneous database and application thereof.
Background
With the development of hardware and software technologies, the size of data is continuously increased, and a traditional database taking a CPU as a computing core cannot cope with the increasingly large-scale data. Thus, a collection of heterogeneous databases that expedite large-scale data processing analysis has emerged. The heterogeneous database system based on the traditional database not only retains friendly support on transactional loads, but also improves the processing performance on analytic loads, and a common heterogeneous database system architecture is shown in fig. 1. Conventional databases typically execute query statements in a manner that interprets execution. On the premise that the heterogeneous database system executes query, the calculation-intensive operators are rewritten into GPU operators, the calling logic of the database is on the CPU side, the GPU is mainly responsible for the calculation logic of the operators, data need to be copied from a memory to a display memory before the GPU executes calculation, and after the GPU is finished, the data need to be copied back to the memory from the display memory for the next operator to use. Therefore, when the query plan includes multiple GPU operators, the data is copied back and forth in the memory and the video memory. Redundant data transmission between heterogeneous devices may occur. Furthermore, frequent starting of the CUDA kernel incurs significant starting costs. Both of which affect the efficiency of execution of the query. The operator fusion can reduce the back-and-forth transmission of data among heterogeneous devices and the starting times of kernel functions.
The existing heterogeneous database system based on the traditional database only supports the basic operator fusion schemes of scanning-connection, scanning-aggregation, scanning-connection-aggregation and the like, and does not consider the operator combination which appears after the sub-query in the query statement is rewritten through the query. For example, the TPC-H Q18 contains sub-queries, and fig. 2 shows an execution plan of a conventional database after rewriting the sub-queries, in which an operator combination of "Scan (Scan) -aggregate (Agg) -Join (Join)" appears. If the operators are executed in the GPU, the operators cannot be fused in the heterogeneous database system due to the lack of corresponding operator fusion strategies, and therefore query efficiency is affected. Therefore, the operator fusion strategy in the existing heterogeneous database system ignores the special scene of the sub-query, new operator combinations appear in the sub-query scene after query rewriting, and how to find the new operator combinations and the complexity of engineering implementation need to be considered in technical implementation.
Disclosure of Invention
In order to solve the defects in the prior art, the invention aims to provide a method for accelerating GPU operator execution in a heterogeneous database, so that the overall performance of query is improved.
The specific technical scheme for realizing the purpose of the invention is as follows:
the invention provides a method for accelerating GPU operator execution in a heterogeneous database system, and relates to a fusion strategy for GPU operator execution in the heterogeneous database. The heterogeneous database system is based on a traditional database and is a collection of a plurality of related databases.
Specifically, the method of the invention realizes the accelerated execution of the GPU operator by judging whether the combination of the specific operators needs to be fused in the query optimization stage and inquiring according to the scheme after query optimization in the query execution stage, and specifically comprises the following steps:
s1, acquiring a query plan generated by a heterogeneous database system based on a traditional database for a query statement;
s2, determining whether a special execution plan generation strategy is considered according to whether a GPU operator is used by the query plan; if a GPU operator is used, a special execution plan generation strategy is considered; if the GPU operator is not used, the special execution plan generation strategy is not considered;
s3, judging whether fusion is effective or not and deciding whether to place an operator on a GPU or not by considering the fused operator cost for the operators in the specific operator combination through a cost estimation method;
s4, after the operator in the specific combination is determined to be placed on the GPU, a specific fusion execution strategy is selected;
and S5, the heterogeneous database system operates the execution plan according to the fusion execution strategy.
In the invention, in step S1, a traditional database and a heterogeneous database system are selected according to actual needs, wherein the traditional database comprises PostgreSQL, openGauss and DB2, and the heterogeneous database system comprises PG-Strom and DB2 with BLU.
In step S1, the query plan in the heterogeneous database is a query plan generated by the heterogeneous database system by means of a conventional database, that is, a set of steps executed to complete a query. Traditional database generated query plans contain only CPU operators. The query plan generated by the heterogeneous database system contains heterogeneous operators, namely a CPU operator and a GPU operator.
In the invention, the GPU used in the step S2 is one or more of a physical GPU or a virtual GPU, and the GPU operator runs on GPU equipment. The physical GPU is a materialized GPU, and the virtual GPU refers to a GPU that is perceived as a separate GPU in use, and is actually a GPU shared by multiple users, and is available through a cloud vendor that provides a cloud host with the GPUs. In recent years, popular heterogeneous database systems almost all adopt the england GPU and develop based on the programming model CUDA, taking into consideration the ecology, the development speed, and the iteration speed of new characteristics of the GPU programming model. The GPU used in the present invention is therefore preferably a GPU produced by Nvidia.
In step S2, the special execution plan generation strategy is to generate an execution plan by considering the fused cost for the specific operator combination. Generally speaking, the higher the cost, the longer the execution time, but the cost cannot be simply considered to mean time consuming.
The specific operator combination is an operator combination which appears after the sub-query is subjected to query rewriting, and the query rewriting is equivalent logic transformation of the original query and converts the SQL statement input by the user into a more efficient equivalent SQL statement. Query rewrite follows two basic principles, equivalence and efficiency. Common query rewrite techniques include constant folding, sub-query boosting, and the like. Constant folding means that before the execution of the SQL statement, the result of the constant expression can be pre-calculated to improve the efficiency, for example, a <2 x 3 is rewritten to a <6. The sub-queries are easier to understand for developers and are not efficient to execute, so that the database can eliminate the sub-queries through a sub-query lifting technology, and the sentences containing the sub-queries are rewritten into connection sentences or sub-query content is calculated independently to realize the queries with the same functions. By performing equivalent transformation on the original query, a better execution effect can be achieved. The specific operator combination comprises an aggregation-join operator, a scanning operator-aggregation operator-join operator, a scanning-aggregation-join-aggregation operator and the like, and compared with the existing operator combination, the specific operator combination after being inquired and rewritten can generate difference in engineering implementation complexity.
In step S2, if the GPU operator is not used, the execution is performed according to the original execution plan generation strategy.
In step S3, the cost estimation method estimates the execution cost of the GPU operator by obtaining statistical information provided by the kernel in the database, such as information about the number of tuples in the table, the selection rate, the number of rows in the table, the length of tuples, and the column and index, and by additionally considering the transmission cost of data in the video memory and the memory according to the CPU calculation cost, the IO cost, and the heterogeneous database. Taking a GPU connection operator as an example, the number of tuples of two tables which are expected to participate in connection and the data size of the tables are obtained by a method provided by a database, and the calculation cost of the operator can be estimated by multiplying the tuple number by a calculation cost coefficient set according to an empirical value; the transmission cost of the data between the memory and the video memory can be estimated by multiplying the data quantity of the table by the data transmission cost coefficient. Summing the costs to be considered is the cost of the operator.
When the fusion is judged to be effective, different operator costs can be estimated according to different data volumes participating in data transmission and calculation before and after the fusion, if the operator cost after the fusion is smaller than the operator cost before the fusion, the fusion is considered to be effective, and at the moment, the GPU operator is fused and placed on the GPU.
In step S3, if the operator cost after fusion is greater than the operator cost before fusion, operator fusion is not performed, and the query plan is directly executed.
In the invention, in step S4, the specific fusion execution strategy corresponds to the specific operator combination, and binds a plurality of operators in the specific operator combination together for execution.
For example, when a scanning operator, an aggregation operator and a connection operator appear in the query plan, the three GPU operators are selected to be fused and executed, that is, data is fixed in a display memory during the execution of the operators and is not copied back to the memory. Other operator combinations work the same way.
In the present invention, in step S5, the execution plan is an execution scheme that finally includes the operator specific implementation and the operator placement position.
The invention also provides application of the method in accelerating GPU operator execution in a heterogeneous database system.
The beneficial effects of the invention include:
compared with the prior art, the invention has obvious advantages and beneficial effects. By means of the technical scheme, the method for accelerating the GPU operator execution in the heterogeneous database system can achieve considerable technical progress and practicability, has industrial wide utilization value, and at least has the following advantages:
the method is based on a heterogeneous database system, faces to the operator combination after the sub-query rewriting, can find more operator combinations which can be fused through the sub-query rewriting means, expands the fusible query types, and for the query sentences containing the sub-query, the operator fused data is continuously operated by a plurality of operators on a GPU, reduces redundant data transmission, reduces the starting cost of a CUDA kernel function, and achieves the purpose of improving the overall query performance. Furthermore, with this approach, if more GPU operators are implemented, then fusible operator combinations can be added.
Drawings
FIG. 1 is a diagram of a heterogeneous database system architecture according to an embodiment of the present invention;
FIG. 2 is a schematic diagram of a sample Query plan of a TPC-H Query-18 as referred to in the prior art;
FIG. 3 is a flowchart illustrating a method for accelerating GPU operator execution according to the present invention.
Detailed Description
The present invention will be described in further detail with reference to the following specific examples and the accompanying drawings. The procedures, conditions, experimental methods and the like for carrying out the present invention are general knowledge and common general knowledge in the art except for the contents specifically mentioned below, and the present invention is not particularly limited.
Some example embodiments are described as processes or methods depicted as flowcharts. Although a flowchart may describe the steps as a sequential process, many of the steps can be performed in parallel, concurrently, or simultaneously. In addition, the order of the steps may be rearranged. A process may be terminated when its operations are completed, but may have additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc.
With the development of hardware and software technologies, the size of data is increasing, and the traditional database with a CPU as a computing core cannot cope with the increasing large-scale data. Thus, a collection of heterogeneous databases that expedite large-scale data processing analysis has emerged. A heterogeneous database system based on a traditional database not only retains friendly support for transactional loads, but also improves processing performance for analytic loads, and a common heterogeneous database system architecture is shown in fig. 1 and includes a query analysis module, a query optimization module, a query execution module, a storage management module, and a GPU function expansion module. Conventional databases typically execute query statements in a manner that interprets execution. On the premise, when the heterogeneous database system executes query, the compute-intensive operators are rewritten into GPU operators, and since the calling logics of the database are all arranged on the CPU side, when the query plan contains a plurality of GPU operators, redundant data transmission can occur among heterogeneous devices. In addition, frequent startup of the CUDA kernel incurs significant startup costs. Both of which affect the efficiency of execution of the query. The operator fusion can reduce the back-and-forth transmission of data among heterogeneous devices and the starting times of kernel functions.
The existing heterogeneous database system based on the traditional database only supports the basic operator fusion schemes of scanning-connection, scanning-aggregation, scanning-connection-aggregation and the like, and does not consider the operator combination which appears after the sub-query in the query statement is rewritten through the query. For example, the TPC — H Q18 contains sub-queries, and fig. 2 shows a query plan after the conventional database rewrites the sub-queries, in which a "scan-aggregate-join" operator combination appears. If the operators are executed in the GPU, the operators cannot be fused in the heterogeneous database system due to the lack of corresponding operator fusion strategies, and therefore query efficiency is affected. Therefore, the operator fusion strategy in the existing heterogeneous database system ignores new combinations of sub-queries after query rewriting. Therefore, how to perform GPU operator fusion on new combinations which appear after the sub-queries are rewritten through queries becomes a technical problem to be solved.
In order to solve the above technical problem, an embodiment of the present invention provides a method for accelerating GPU operator execution in a heterogeneous database system. The method has the core idea that whether a special execution plan generation strategy is considered or not is determined by means of a query plan generated by a heterogeneous database according to whether a GPU operator is used or not, whether the operator is placed in the GPU or not is selected from the bottom up, whether fusion is effective or not is judged by a cost estimation method when whether the operator is placed in the GPU or not is determined for operator combinations (such as scanning-aggregation-connection) appearing after sub-query rewriting, and finally, the operator in a specific operator combination is executed by adopting a corresponding fusion strategy. By the method, data transmission cost of cross-heterogeneous equipment and cost of starting the CUDA kernel function can be effectively reduced, and query execution efficiency is improved.
Fig. 3 is a flowchart of a method for accelerating GPU operator execution by fusing a specific GPU operator combination in a heterogeneous database system based on a conventional database according to an embodiment of the present invention. The method comprises the following steps:
and S1, receiving the query sentence of the user by the heterogeneous database system, performing lexical and syntactic analysis to generate an abstract syntax tree, performing primary rewriting according to rules (such as projection elimination, predicate push-down and the like) and generating a query plan. Acquiring a query plan generated by a heterogeneous database system;
by way of example, FIG. 2 is a preliminary query plan generated by the heterogeneous database system PG-Strom via PostgreSQL. The query plan is a logical query plan, i.e. it does not involve the concrete implementation and placement of operators.
S2, determining whether a special execution plan generation strategy is considered according to whether a GPU operator is used by the query plan;
s3, judging whether fusion is effective or not and deciding whether to place an operator on a GPU or not by considering the fused operator cost for the operators in the specific operator combination through a cost estimation method;
as an example, a particular operator combination is a new operator combination generated by rewriting a sub-query, such as the "scan-aggregate-join" operator combination in FIG. 2.
It should be noted that the specific implementation of the operator and the determined order of the placement positions are bottom-up. In the determination process, if an operator in a specific operator combination appears, since the cost of data transmission and CUDA kernel function starting can be reduced after fusion, the specific implementation and placement position of the operator need to be determined by considering the lower cost of the operator after fusion. Wherein, the estimation of the operator cost is performed by means of statistical information in the database system (such as the row number of the table, the tuple length, and the related information of the column and the index).
S4, selecting a specific fusion execution strategy after deciding to place the operators in the specific combination on the GPU;
as an embodiment, the specific fusion execution policy corresponds to a specific operator combination, that is, the fusion execution policy is oriented to a new operator combination after the sub-query is rewritten.
And S5, the heterogeneous database system operates the execution plan according to the fusion execution strategy.
The method is based on a heterogeneous database system, the operator combination after the sub-query rewriting is oriented, the fusible operator combination is expanded, the fusible query type is expanded, and for the query statement containing the sub-query, the starting cost of redundant data transmission and the CUDA kernel function can be reduced, so that the aim of improving the overall query performance is fulfilled.
As an embodiment, the embodiment of the present invention can be applied to a series of conventional databases developed based on a PostgreSQL kernel by using a heterogeneous database system such as PG-from.
After a heterogeneous database system based on a traditional database is deployed and started on the basis of a server provided with a GPU card, a user sends a query statement to the server through a client. After receiving the query statement, the server performs a series of operations on the query statement until a query result is obtained and returns the query result to the client. The series of operations comprise lexical grammar analysis, query optimization and query execution. The method of the invention judges whether the fusion of the specific operator combination is needed or not in the query optimization stage, and then executes the fusion according to the corresponding execution strategy in the query execution stage.
The protection of the present invention is not limited to the above embodiments. Variations and advantages that may occur to those skilled in the art may be incorporated into the invention without departing from the spirit and scope of the inventive concept, which is set forth in the following claims.
Claims (10)
1. A method for accelerating GPU operator execution in a heterogeneous database system is characterized in that query task execution in the heterogeneous database system comprises three stages of query analysis, query optimization and query execution.
2. The method of claim 1, wherein the method comprises the steps of:
s1, acquiring a query plan generated by a heterogeneous database system based on a traditional database for a query statement;
s2, the query plan determines whether a special execution plan generation strategy is considered or not according to whether a GPU operator is used or not; if a GPU operator is used, a special execution plan generation strategy is considered; if the GPU operator is not used, the special execution plan generation strategy is not considered;
s3, judging whether fusion is effective or not and determining whether the operator is placed on the GPU or not by considering the fused operator cost for the operator in the specific operator combination through a cost estimation method;
s4, selecting a specific fusion execution strategy after deciding to place the operators in the specific combination on the GPU;
and S5, the heterogeneous database system operates the execution plan according to the fusion execution strategy.
3. The method according to claim 2, wherein in step S1, the legacy database includes PostgreSQL, openGauss, DB2, and the heterogeneous database system includes PG-Strom, DB2 with BLU;
the query plan in the heterogeneous database is a query plan generated by the heterogeneous database system by means of a traditional database, namely a group of steps executed for completing query; the query plan generated by the heterogeneous database system comprises heterogeneous operators, namely a CPU operator and a GPU operator.
4. The method according to claim 2, wherein in step S2, the GPU is one or more of a physical GPU or a virtual GPU, and the GPU operator runs on a GPU device; the physical GPU is an materialized GPU, and the virtual GPU refers to a GPU which is provided by a cloud manufacturer with a GPU cloud host and shared by a plurality of users;
the special execution plan generation strategy is to generate an execution plan by considering the fused cost for a specific operator combination; the specific operator combination is an operator combination which appears after the sub-query is subjected to query rewriting, and the query rewriting refers to performing equivalent transformation on the query based on an optimization rule so as to achieve a better execution effect; the specific operator combination comprises aggregation-join operator, scanning operator-aggregation operator-join operator and scanning-aggregation-join-aggregation operator.
5. The method of claim 4, wherein said query reformulation is converting a user-entered SQL statement to a more efficient equivalent SQL statement by performing an equivalent logical transformation on the original query; the query rewriting follows equivalence and high efficiency, and a better execution effect is achieved through a query rewriting technology including constant folding and sub-query promotion;
the constant folding refers to that a constant expression is subjected to pre-calculation to obtain a result before the SQL statement is executed;
the sub-query lifting means that a statement containing the sub-query is rewritten into a connection statement or sub-query contents are independently calculated to realize the query with the same function as before rewriting.
6. The method according to claim 2, wherein in step S3, the cost estimation method is to estimate the execution cost of the GPU operator by obtaining statistical information provided by a database kernel, and by calculating cost according to a CPU, IO cost, and transmission cost of data in a video memory and a memory that needs to be additionally considered for a heterogeneous database; the statistical information includes the tuple number of the table, the selection rate, the row number of the table, the tuple length, and the information of the column and the index.
7. The method according to claim 2, wherein in step S3, when determining whether the fusion is valid, different operator costs are estimated according to different data amounts participating in data transmission and calculation before and after the fusion, and when the operator cost after the fusion is smaller than the operator cost before the fusion, the fusion is considered to be valid, and at this time, the GPU operator is fused and placed on the GPU.
8. The method of claim 2, wherein in step S4, the specific fusion execution strategy corresponds to a specific operator combination, and the operators in the specific operator combination are bound together for execution.
9. The method of claim 2, wherein in step S5, the execution plan is an execution plan that ultimately contains operator specific implementations and operator placement positions.
10. The method of any one of claims 1-9 accelerating applications in GPU operator execution in a heterogeneous database system.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211459169.4A CN115794874A (en) | 2022-11-16 | 2022-11-16 | Method for accelerating GPU operator execution in heterogeneous database system and application |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211459169.4A CN115794874A (en) | 2022-11-16 | 2022-11-16 | Method for accelerating GPU operator execution in heterogeneous database system and application |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115794874A true CN115794874A (en) | 2023-03-14 |
Family
ID=85439575
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211459169.4A Pending CN115794874A (en) | 2022-11-16 | 2022-11-16 | Method for accelerating GPU operator execution in heterogeneous database system and application |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115794874A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116665020A (en) * | 2023-07-31 | 2023-08-29 | 国网浙江省电力有限公司 | Image recognition method, device, equipment and storage medium based on operator fusion |
| CN116954721A (en) * | 2023-09-20 | 2023-10-27 | 天津南大通用数据技术股份有限公司 | Asynchronous non-blocking splitting method for multi-modal operator of actuator |
-
2022
- 2022-11-16 CN CN202211459169.4A patent/CN115794874A/en active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116665020A (en) * | 2023-07-31 | 2023-08-29 | 国网浙江省电力有限公司 | Image recognition method, device, equipment and storage medium based on operator fusion |
| CN116665020B (en) * | 2023-07-31 | 2024-04-12 | 国网浙江省电力有限公司 | Image recognition method, device, equipment and storage medium based on operator fusion |
| CN116954721A (en) * | 2023-09-20 | 2023-10-27 | 天津南大通用数据技术股份有限公司 | Asynchronous non-blocking splitting method for multi-modal operator of actuator |
| CN116954721B (en) * | 2023-09-20 | 2023-12-15 | 天津南大通用数据技术股份有限公司 | Asynchronous non-blocking splitting method for multi-modal operator of actuator |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7370043B1 (en) | Method and system for upgrade validation of database query plans | |
| CN115794874A (en) | Method for accelerating GPU operator execution in heterogeneous database system and application | |
| US7984043B1 (en) | System and method for distributed query processing using configuration-independent query plans | |
| US10372707B2 (en) | Query execution pipelining with pump operators | |
| US10733184B2 (en) | Query planning and execution with source and sink operators | |
| US6009265A (en) | Program product for optimizing parallel processing of database queries | |
| US20170083573A1 (en) | Multi-query optimization | |
| US8135703B2 (en) | Multi-partition query governor in a computer database system | |
| US8396852B2 (en) | Evaluating execution plan changes after a wakeup threshold time | |
| US7689612B2 (en) | Handling of queries of transient and persistent data | |
| US11061895B2 (en) | Adaptive granule generation for parallel queries with run-time data pruning | |
| US20140280030A1 (en) | Method of converting query plans to native code | |
| US20110167056A1 (en) | Parameter-sensitive plans | |
| US20180150513A1 (en) | Query Execution Pipelining with Shared States for Query Operators | |
| JPH07319923A (en) | Method and equipment for processing of parallel database of multiprocessor computer system | |
| CN107315790A (en) | A kind of optimization method and device of irrelevant subquery | |
| US20130318068A1 (en) | Method for serial and condition-based execution of operators by parallel processes | |
| CN111581234B (en) | RAC multi-node database query method, device and system | |
| US20210224257A1 (en) | Group-by efficiency though functional dependencies and non-blocking aggregation functions | |
| CN110909077A (en) | Distributed storage method | |
| EP3396542B1 (en) | Database operating method and device | |
| Tatemura et al. | Partiqle: An elastic SQL engine over key-value stores | |
| US10860579B2 (en) | Query planning and execution with reusable memory stack | |
| US8380701B1 (en) | Using a partially built index in a computer database system | |
| US11455303B2 (en) | Driving massive scale out through rewrites of analytical functions |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |