KR20180104498A - Method and apparatus for processing query - Google Patents

Abstract

A query execution method of a query executor is provided. The query executor receives a physical query plan tree. The query executor determines whether the first operator among the operators included in the physical query plan tree is a special operator processed in a JIT (just in time) compilation method. The query executor determines whether there is a first low level virtual machine (LLVM) intermediate representation operator corresponding to the first operator when the first operator is the special operator. The query executor converts the first LLVM IR operator into a machine code and executes the first LLVM IR operator when the first LLVM IR operator exists.

Description

[0001] METHOD AND APPARATUS FOR PROCESSING QUERY [0002]

The present invention relates to a method and apparatus for query processing in the database field.

In a conventional database management system (DBMS), a query processing method generally includes parsing a query, checking errors, performing optimization, and executing an optimized query plan through a query executor Follow the process.

The process that the query executor finally executes among these query processing processes traditionally uses an interpreter type query executor. At this time, the interpreter-based query execution unit performs a conventional volcano-based iterator model query processing that circles each plan in the query execution plan tree and executes each query plan.

Such a volcano method calls a lot of function calls and has a disadvantage that the execution speed is slow. In order to improve the conventional iterative query execution method, there is a need for a query execution technique based on JIT (Just-In-Time) compilation. The JIT compilation-based query execution method is a compiler method, not an interpreter method.

If this JIT compilation method is used, the query execution speed can be improved. However, the JIT compilation method requires a separate compile time because the runtime compilation process is performed during the execution of the query. This approach may only be appropriate for OLAP (online analytical processing) queries because it may take longer to perform all execution plans in a JIT compilation manner in the case of an OLTP (online transaction processing) query.

However, when the OLTP query is performed, even if the relational operator with a low query processing load is processed through the existing interpreter method, there is little problem in performance. However, performance problems may arise if relational operators have complicated operations and specific operators (eg, join operators, sorting operators) that perform a lot of comparison operations are processed through the existing interpreter method. In particular, when a join operator is processed, many accesses to a table may be performed according to a join condition, and many functions may be called.

Even in the case of OLTP queries, the performance can be improved if the JIT compilation method is partially used, rather than the interpreter method, for such operators with a high computational load.

SUMMARY OF THE INVENTION The present invention provides a method and an apparatus for solving performance degradation according to an interpreter-based query processing method in a method of performing a query processing in a DBMS (for example, a method of executing an execution plan) will be.

Another object of the present invention is to provide a method and apparatus for reducing compilation time and improving overall performance.

Another object of the present invention is to provide a method and apparatus for improving the performance of a query processing using a JIT compilation method rather than an interpreter method for specific operators having a large computation load.

Another object of the present invention is to provide a method and an apparatus for executing a query execution plan in a general interpreter method for a general operator with a small load.

According to an embodiment of the present invention, a method for processing a query executor query is provided. The query processing method of a query executor includes: receiving a physical query plan tree; Determining whether the first operator among the operators included in the physical query plan tree is a special operator that is processed in a JIT (just in time) compilation method; If the first operator is the special operator, determining whether a first low level virtual machine (LLVM) intermediate representation (LLVM) operator corresponding to the first operator exists; And converting the first LLVM IR operator into a machine code and executing the first LLVM IR operator if the first LLVM IR operator exists.

The special operator may have a larger computational load than a general operator that is processed by an interpreter method.

The step of determining whether the first operator is the special operator may include determining the first operator as the special operator when the first operator exists in the pre-stored special operator list.

The list of special operators can be modified.

The special operator list can be updated based on the operation execution time of each operator executed for query processing.

The method of claim 1, wherein if the first LLVM IR operator does not exist, the query executor converts the first operator into the first LLVM IR operator, And converting the code into a code and executing the code.

The converting and executing the first LLVM IR operator into a machine code may include optimizing the first LLVM IR operator; And converting the optimized first LLVM IR operator to machine code.

The query processing method of the query executor may further include executing the first operator in the interpreter manner when the first operator is the general operator.

The query executor may be included in a query processor of a database management system (DBMS) server.

The physical query plan tree may be generated through optimization of a logical query plan configured for the query sentence.

According to another embodiment of the present invention, a query executor is provided. The query executor processes the first operator in a JIT (just in time) compilation method among the operators included in the physical query plan tree when a physical query plan tree is input. An operator manager for determining whether the operator is a special operator or an ordinary operator processed in an interpreter manner; An LLVM IR manager that verifies whether a first low level virtual machine (LLVM) intermediate representation operator corresponding to the first operator exists if the first operator is the special operator; An LLVM IR generator for converting the first operator into the first LLVM IR operator and transmitting the first operator to the LLVM IR manager when the first LLVM IR operator does not exist; And an LLVM IR cache manager for transferring the previously stored first LLVM IR operator to the LLVM IR manager when the first LLVM IR operator exists.

The query executor may further include an LLVM IR optimizer that optimizes the first LLVM IR operator when the first LLVM IR operator is received from the LLVM IR manager.

The query executor may further include an LLVM IR operator executor that converts the optimized first LLVM IR operator into machine code and executes the machine code.

The query executor may further include an interpreter operator executor that executes the first operator in the interpreter manner when the first operator is the general operator.

The operator manager can determine the first operator as the special operator when the first operator exists in the previously stored special operator list.

The operator manager can update the special operator list based on the execution time of each operator executed for query processing.

The operator manager can modify the special operator list according to a user's request.

According to the embodiment of the present invention, in the case where the query execution unit performs query processing on the execution plan tree in the query processing process, the performance improvement can be improved by applying the JIT compilation process to the operator with a heavy computation load.

Also, according to the embodiment of the present invention, by applying the interpreter method to a general operator having a small computational load, an efficient method can be performed according to operator characteristics. Through this, the overall performance can be improved.

1 is a diagram showing a general database system.
2 is a diagram showing a query processing process in the database system.
FIG. 3 is a diagram illustrating a query processing procedure and a detailed configuration necessary for the query processing according to an embodiment of the present invention.
4 is a diagram illustrating a process in which a query processor performs a query process according to an embodiment of the present invention.
5 is a diagram of a computing device, in accordance with an embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily carry out the present invention. The present invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. In order to clearly illustrate the present invention, parts not related to the description are omitted, and similar parts are denoted by like reference characters throughout the specification.

In the present specification, duplicate descriptions are omitted for the same constituent elements.

Also, in this specification, when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, May be present. On the other hand, in the present specification, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that no other element exists in between.

Furthermore, terms used herein are used only to describe specific embodiments and are not intended to be limiting of the present invention.

Also, in this specification, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise.

Also, in this specification, the terms " comprise ", or " have ", and the like are used to specify that there is a feature, a number, a step, an operation, an element, a component, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, parts, or combinations thereof.

Also, in this specification, the term 'and / or' includes any combination of the listed items or any of the plurality of listed items. In this specification, 'A or B' may include 'A', 'B', or 'both A and B'.

Hereinafter, a method and apparatus for maximizing query processing performance by strategically using an interpreter method and a JIT compilation method in a query processing method for a DBMS will be described. Specifically, a method and apparatus for efficient query processing based on JIT compilation for a special operator (eg, time-consuming and data-intensive operator) having a heavy query processing load will be described.

In particular, in the case of the OLTP query, since the execution time is generally shorter than that of the OLAP query, the query is mostly executed through the interpreter method. In this case, there is no big problem for the general operator, but the operation cost of a specific operator (for example, a join operator, a sort operator, etc.) which is complicated and performs a lot of comparison operations may occur. If the query for performing such an operation is executed through the interpreter method, there is a disadvantage that the overall query processing speed is rapidly deteriorated.

In order to overcome the drawbacks of performance degradation, a method of differentiating a general operator having a small operation cost and a specific operator having a large operation cost differently can be used in consideration of the operation cost of the operator in the query processing execution method. Concretely, a method of providing the function of selecting the optimum processing method according to the type of operator by using the interpreter method and the JIT compilation method in parallel can be used. In this way, optimal query performance can be improved. For example, in a query processing method for an OLTP query, a different query execution method can be used for a general operator and a specific operator (for example, a high-load operator such as a join operator, a sorting operator, etc.) A query processing method of a compilation method other than an interpreter method may be applied.

Meanwhile, the method according to the embodiment of the present invention is not limited to a specific DBMS system. For example, the method according to an embodiment of the present invention can be widely applied not only to a disk-based DBMS but also to an in-memory-based DBMS.

1 is a diagram showing a general database system.

Specifically, FIG. 1 illustrates an overall configuration of a general database system as a basis for describing a query processing method according to an embodiment of the present invention.

1, the DBMS server 102 includes a query processor 103, a storage manager 104, and a storage 105 in which data is stored. A structured query language (SQL) query 101 is input to the DBMS server 102.

The storage 105 includes actual data, indexes and metadata necessary for efficiently processing data accesses, and the like.

The storage manager 104 manages access to data on the disk or memory.

The query processor 103 analyzes and parses the query sentence of the content queried by the user, checks whether or not there is an error in the query, optimizes the query, and performs the actual query processing .

Next, the detailed module (or detailed configuration) included in each of the configurations 103, 104, and 105 of the DBMS server 102 will be described.

1, the query processor 103 includes a query parser 106, a query preprocessor 107, a query optimizer 108, and an interpreter based query executor and an interpreted executor 109.

The query parser 106 analyzes the inputted user query sentence (e.g., 101) to generate a parse tree.

The query preprocessor 107 confirms whether there is an error in the inputted query syntax, and converts the parse tree into a logical query plan (or logical tree).

The query optimizer 108 interprets the logical query plan (or logical tree), converts it into an optimized form, and converts it into a physical query plan (or physical tree).

The query execution unit 109 performs query processing for each operator while visiting operators included in the optimized physical query plan (or physical tree), and transmits each query result to the next operator to inquire about the corresponding operator Processing is performed.

1, the storage manager 104 includes a buffer manager 110, a file manager 111, a lock manager 112, a transaction manager 113, And a recovery manager 114 and the like.

The buffer manager 110 provides a function for efficiently loading and using data stored in a disk or an in-memory.

The file manager 111 provides a function for processing an operation of reading or writing an actual data file in the storage 105. [

The lock manager 112 provides a data access control function to prevent a problem from occurring when multiple users access one data at the same time.

The transaction manager 113 provides transaction management functions for each operation in order to maintain the most important consistency in the database system.

The recovery manager 114 provides a recovery function for when a failure occurs.

1, the storage 105 includes a module for storing and managing actual data to be stored, various index information for quickly and efficiently processing data access, and various system information and metadata necessary for actual data management .

2 is a diagram showing a query processing process in the database system.

Specifically, FIG. 2 illustrates a general query processing process performed by the query processor 103.

As illustrated in FIG. 2, when a query sentence (e.g., SQL query) inquired by the user is input (S201), the query parser 106 of the query processor 103 receives a query sentence and analyzes the query syntax The query preprocessor 107 of the query processor 103 performs an error analysis on the query sentence (S202). If there is no error, the query processor 103 performs a function of generating a logical query plan (S203).

The query optimizer 108 of the query processor 103 receives the generated logical query plan and generates an optimized physical query plan that can be performed in an optimized manner in which the cost among the possible query plans is minimized (S204).

The query execution unit 109 of the query processor 103 receives the optimized physical query plan tree (S205), performs the physical operator while searching from the root node of the optimized physical query plan tree, and outputs the result to the input (S206). The process of performing such a plan is performed until all the last operator plan is executed (S206).

After all the operators are executed, the query results generated are passed to the user.

FIG. 3 is a diagram illustrating a query processing procedure and a detailed configuration necessary for the query processing according to an embodiment of the present invention.

Specifically, FIG. 3 illustrates a process and module (or configuration) for performing a JIT compilation for a particular operator.

In FIG. 3, the query execution unit 109a used for the query processor 103 performs a preprocessing process for performing an optimized physical plan (e.g., inputting a user query sentence, constructing a logical query plan, and optimizing a logical query plan And a method of constructing a physical query plan) follows a general processing method performed by an existing DBMS server, similar to that described in FIG. 2 (S301 to S305).

In order to perform the query processing, a query execution unit 109a for executing the optimized physical query plan tree generated in the preceding steps (S301 to S305) is executed. When the query execution unit 109a executes only the existing interpreter type query processing method The JIT compilation processing method and the interpreter query processing method will be described in an optimal manner according to the characteristics of the query operator.

Depending on the type of operator in the physical query plan, computing costs for operator processing are different. In particular, in the case of an operator such as a join, a cost for query processing may be increased depending on a join condition. In addition, even in the case of an operator such as sorting, since a lot of comparison operations are performed among a plurality of data, a computation query processing tendency tends to occur. In the case of these special operators (for example, join operator, sorting operator, group-by operator, etc.), the processing cost is higher than that of general operators. When the conventional interpreter method is applied to such a large-load operator (special operator), a continuous function call occurs, which causes a lot of operation costs and the processing speed is remarkably slow.

In order to overcome this problem, a method of performing an interpreter-based query processing for a general operator and a query processing of a JIT compilation method for a special expensive operator will be described.

The query processor 103 parses the query parser 106 and the query preprocessor 107 with respect to an inputted query sentence (e.g., SQL query) And generates an optimized physical query plan through optimization of the query optimizer 108 (S301 to S305). That is, the optimized physical query plan (physical query plan tree) is a logical query plan composed of a parsing of the query parser 106 and a preprocessing of the query preprocessor 107 with respect to the inputted query sentence, Lt; RTI ID = 0.0 > 108 < / RTI >

The physical query plan optimized by the query optimizer 108 is delivered to the query executor 109a according to the embodiment of the present invention (S306).

The query executor 109a includes an operator manager 109a-1, an LLVM IR manager 109a-2, an LLVM IR generator 109a-3, an LLVM IR cache manager 109a-4, an LLVM IR optimizer 109a-5 ), An LLVM IR operator launcher 109a-6, and an interpreter operator launcher 109a-7.

The operator manager 109a-1 determines the type of operator included in the input physical query plan (physical query plan tree) (S307). Specifically, the operator manager 109a-1 determines whether the corresponding operator is a JIT compilation process target (for example, a special operator processed by the JIT compilation query processing method), an interpreter type process target (for example, (S307). ≪ / RTI >

When the operator manager 109a-1 selects an object to be JIT compiled among the operators to be subjected to the query processing, special operators having a heavy computation load may be previously selected and registered (or stored) in the system in advance. Or a special operator may be selected by the user at the time of system execution. Also, the operator manager 109a-1 can update the information on the special operator (e.g., list of special operators, etc.) by measuring the operator execution time based on the query execution result, It can be used to select an object. Through these methods, a method of flexibly selecting a special operator to be subjected to JIT compilation can be provided in consideration of a system or a user environment.

Basically, at the time of system startup, a function of selecting, registering and providing special operators to be subjected to JIT compilation processing among the operators analyzed in advance may be provided. Alternatively, when the system is executed, a function may be provided in which a user adds another operator to the special operators to be provided in the existing JIT compilation process, or the operator deletes the operator in the special operators to be JIT compiled. These functions may be provided by the operator manager 109a-1. For example, the operator manager 109a-1 can determine the operator as a special operator when the operator is present in the list of special operators (stored). The operator manager 109a-1 can modify the list of special operators according to the user's request (for example, add special operators, delete special operators, etc.). The operator manager 109a-1 can update the special operator list based on the execution time of each operator executed for the query processing.

As a result of the determination by the operator manager 109a-1, when the corresponding operator is a JIT compilation processing object due to a large execution load (that is, when the operator is a special operator), an intermediate representation manager (LLVM) 109a-2) is called (S308).

The LLVM IR manager 109a-2 performs a task of converting the special operator determined as a JIT compilation target into LLVM IR, which is an intermediate language expression (S308). At this time, when the LLVM IR manager 109a-2 performs IR conversion for the special operator to be JIT-compiled, it first checks whether there is a LLVM IR operator created previously through JIT compilation for the special operator.

If the LLVM IR generator 109a-3 has not been previously generated for the particular operator, the LLVM IR generator 109a-3 is called (S309) and the LLVM IR generator 109a-3 generates the special operator To the LLVM IR operator (S309). Then, the LLVM IR generator 109a-3 transmits the newly created LLVM IR operator to the LLVM IR manager 109a-2.

If the LLVM IR manager 109a-2 has previously generated the LLVM IR operator for the special operator, the LLVM IR manager 109a-2 requests the LLVM IR cache manager 109a-4 to transfer the special operator And the LLVM IR operator generated in step S310.

The LLVM IR manager 109a-2 fetches the LLVM IR operator through the LLVM IR generator 109a-3 or imports the LLVM IR operator already cached (or stored) through the LLVM IR cache manager 109a-4 , And transmits it to the LLVM IR optimizer 109a-5 (S308).

In order to improve the performance, the LLVM IR optimizer 109a-5 performs an operator optimization process on the LLVM IR operator to be performed (S311). At this time, the LLVM IR optimizer 109a-5 can perform various optimizations by configuring various optimization algorithms through the optimization function provided by the LLVM framework.

The LLVM IR operator executor 109a-6 executes the optimized LLVM IR operator through the LLVM IR optimizer 109a-5 for query processing (S312). Specifically, the LLVM IR operator launcher 109a-6 can be implemented by converting the optimized LLVM IR operator into machine code. The result obtained through the LLVM IR operator launcher 109a-6 is passed to the next operator, which is then used as input for execution of the next operator.

If the operator manager 109a-1 confirms whether the operator is a JIT compilation process target (S307), in the case of an interpreter type process target rather than a JIT compilation process target, an interpreter method The general operator is executed by the operator executor 109a-7 of the terminal (S313). The interpreter operator launcher 109a-7 operates in the same or similar manner as the existing interpreter operator execution method.

4 is a diagram illustrating a process in which a query processor performs a query process according to an embodiment of the present invention.

Specifically, FIG. 4 illustrates a process in which the query execution unit 109a according to the embodiment of the present invention performs a query execution plan.

In Fig. 4, the query executor 109a receives an optimized query execution physical query plan as input (S402).

The query executor 109a visits the first operator among the operators included in the inputted optimized query execution physical plan tree (S403).

The query executor 109a determines whether the operator is a special operator that is a JIT compilation process target or a general operator that is not a JIT compilation process target (S404).

In step S404, the query execution unit 109a determines whether there is a LLVM IR operator cache for the special operator in the case where the operator is a special operator that is the JIT compilation processing target. Specifically, the query executor 109a can determine whether an LLVM IR operator corresponding to the special operator has been previously generated (S405).

The query execution unit 109a uses the JIT IR operator (or the LLVM IR operator) cached (or stored) when the determination result (S405) and the cache in which the LLVM IR operator has already been generated exists and transmits the special operator to the LLVM A new conversion process is not performed using the IR operator (S406).

If the LLVM IR operator cache does not exist, the query executor 109a performs the process of converting the special operator into the LLVM IR operator (S407).

The query executor 109a performs a process of optimizing the LLVM IR operator for the LLVM IR operator (S408). Here, the LLVM IR operator may be a cached (or stored) LLVM IR operator or a newly created LLVM IR operator through step S407.

The query execution unit 109a converts the LLVM IR operator into an machine code corresponding to the target machine, and executes an operator converted to the machine code to obtain an intermediate result for the optimized LLVM IR operator (S409).

If it is determined in operation S404 that the corresponding operator is not a special operator that is a JIT compilation processing object but a general operator, the query execution unit 109a executes the general operator in an interpreter manner to obtain an intermediate result (S410).

The query executor 109a determines whether there is a next operator to perform (S411) after executing the processes of S409 and S410.

The query execution unit 109a repeatedly performs the processing from S403 to S411 when the determination result (S411) and the next operator to be executed are present, and obtains the result.

If there is no next operator to be executed, the query execution unit 109a finally returns the query result and terminates (S412).

5 is a diagram of a computing device, in accordance with an embodiment of the present invention. The computing device TN100 of FIG. 5 may correspond to the DBMS server 102, the query processor 103, or the query executor 109a described in this specification.

In the embodiment of FIG. 5, the computing device TN100 may include at least one processor (TN 110), a transceiver (TN 120) in communication with the network, and a memory (TN 130). Further, the computing device TN100 may further include a storage device TN140, an input interface device TN150, an output interface device TN160, and the like. The components included in the computing device TN100 may be connected by a bus (TN170) and communicate with each other.

The processor TN110 may execute a program command stored in at least one of the memory TN130 and the storage device TN140. The processor TN110 may refer to a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which methods according to embodiments of the present invention are performed. The processor TN110 may be configured to implement the procedures, functions, and methods described in connection with the embodiments of the present invention. The processor TN110 may control each component of the computing device TN100.

Each of the memory TN130 and the storage device TN140 may store various information related to the operation of the processor TN110. Each of the memory TN130 and the storage device TN140 may be constituted of at least one of a volatile storage medium and a nonvolatile storage medium. For example, the memory TN130 may be configured with at least one of a read only memory (ROM) and a random access memory (RAM).

The transceiver apparatus TN120 can transmit or receive a wired signal or a wireless signal.

On the other hand, the embodiments of the present invention are not only implemented by the apparatuses and / or methods described so far, but may also be realized through a program realizing a function corresponding to the configuration of the embodiment of the present invention or a recording medium on which the program is recorded And such an embodiment can be easily implemented by those skilled in the art from the description of the embodiments described above.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, It belongs to the scope of right.

Claims (17)

Receiving a physical query plan tree;
Determining whether the first operator among the operators included in the physical query plan tree is a special operator that is processed in a JIT (just in time) compilation method;
If the first operator is the special operator, determining whether a first low level virtual machine (LLVM) intermediate representation (LLVM) operator corresponding to the first operator exists; And
Converting the first LLVM IR operator into a machine code and executing the first LLVM IR operator if the first LLVM IR operator exists
And a query executor having a query executor. The method according to claim 1,
The special operator
Compared to general operators that are processed in an interpreter manner,
Query processing method of query executor. The method according to claim 1,
Wherein the step of determining whether the first operator is the special operator comprises:
Determining the first operator as the special operator when the first operator exists in the pre-stored special operator list,
The list of special operators
Query processing method of query executor. The method of claim 3,
In the special operator list,
Is updated based on the operation execution time of each operator executed for query processing
Query processing method of query executor. The method according to claim 1,
Converting the first operator into the first LLVM IR operator and converting the first LLVM IR operator into machine code and executing the first LLVM IR operator if the first LLVM IR operator does not exist
Wherein the query executor further comprises a query executor. The method according to claim 1,
The step of converting the first LLVM IR operator into a machine code and executing the first LLVM IR operator,
Optimizing the first LLVM IR operator; And
And converting the optimized first LLVM IR operator to machine code
Query processing method of query executor. 3. The method of claim 2,
Executing the first operator in the interpreter manner if the first operator is the general operator;
Wherein the query executor further comprises a query executor. The method according to claim 1,
The query execution unit,
A database management system (DBMS) server includes a query processor
Query processing method of query executor. The method according to claim 1,
The physical query plan tree comprises:
Generated by optimization of the logical query plan that is constructed for the query sentence
Query processing method of query executor. In a case where a physical query plan tree is input, a first operator among the operators included in the physical query plan tree is a special operator processed in a JIT (just in time) compilation method, an interpreter, An operator manager for determining whether the general operator is a general operator to be processed in a method;
An LLVM IR manager that verifies whether a first low level virtual machine (LLVM) intermediate representation operator corresponding to the first operator exists if the first operator is the special operator;
An LLVM IR generator for converting the first operator into the first LLVM IR operator and transmitting the first operator to the LLVM IR manager when the first LLVM IR operator does not exist; And
An LLVM IR cache manager for transferring the previously stored first LLVM IR operator to the LLVM IR manager when the first LLVM IR operator exists;
A query executor that includes a query executor. 11. The method of claim 10,
An LLVM IR optimizer for optimizing the first LLVM IR operator when receiving the first LLVM IR operator from the LLVM IR manager;
A query executor further comprising: 12. The method of claim 11,
An LLVM IR operator executor that converts the optimized first LLVM IR operator into machine code and executes it
A query executor further comprising: 11. The method of claim 10,
An interpreter operator executor for executing the first operator in the interpreter manner when the first operator is the general operator;
A query executor further comprising: 11. The method of claim 10,
The operator manager,
Determining that the first operator is the special operator when the first operator exists in the pre-stored special operator list,
The operator manager,
The list of special operators is updated based on the execution time of each operator executed for query processing
The query executor. 15. The method of claim 14,
The operator manager,
The special operator list is modified according to the user's request
The query executor. 11. The method of claim 10,
The physical query plan tree comprises:
Generated by optimization of the logical query plan that is constructed for the query sentence
The query executor. 11. The method of claim 10,
Wherein the operator manager, the LLVM IR manager, the LLVM IR generator, and the LLVM IR cache manager,
Used for a query processor in a database management system (DBMS) server.
The query executor.

Images