CLIAMS:
1. A database management system (DBMS) (104) communicably coupled to at least one database server (106) configured to receive at least one database query from at least one database client system (102) for storing data in at least one database (108) of the database server (106), and/or providing the database client system (102) access to the data in response to the database query received, the database management system (DBMS) (104) comprising at least one query compiler (109) configured to prepare an execution plan in a tree structure, with a plurality of plan nodes, for the database query received, and CHARACTERIZED BY COMPRISING:
an identifier module (110) configured to analyze the execution plan to categorize the database query received into simple database query or complex database query, wherein the identifier module categorizes the database query based on presence of at least one of joins clause, or data manipulation language (DML) syntax elements, or a range table list, or based on the plan node, or any combination thereof; and
at least two query executors for the execution of the database query categorized, received from the identifier module, wherein at least one query executor (normal executor) (112) from the two query executors is configured to execute the complex query, and at least one other query executor (slim executor) (114) from the two query executors is configured to execute the simple query.

2. The database management system (DBMS) as claimed in claim 1, wherein the at least one query executor (normal executor) executes the complex query in a conventional query execution manner.

3. The database management system (DBMS) as claimed in claim 1, wherein the at least one other query executor (slim executor) executes the database query received, if the database query comprises at least one of single table on which the operations selected from select, or update, or insert, or delete, or having no join clause, or any combination thereof is/are to be performed.

4. The database management system (DBMS) as claimed in claim 1 and 3, wherein the at least one other query executor (slim executor) comprises:
a node processing module configured to:
process at least one plan node received in the execution plan generated by the query compiler, wherein the plan nodes at the bottom level are table scan nodes and configured to fetch at least one tuple (raw rows) from at least one table using an access layer;
identify a requirement of slots, and/or expression contexts and thereby calls an associated module of the slots, and/or the expression contexts for allocation and management.
an executor state management module configured to:
create an executor state, wherein the executor state comprises information required by the node processing module, selected from a memory context for execution, an external parameter passed to query by a user;
manage execution information and an executor context; and
stores at least one parameter bind to the database query received.
an expression management module configured to:
evaluate expression work, wherein the expression work evaluation comprises a target list evaluation(projection) and qualification check;
a slot management module configured to:
manage at least on slot configured to store at least on tuple information, wherein the tuple information is selected from at least one of forms of tuple i.e., raw tuple, or deformed tuple, or tuple descriptor, or any combination thereof.

5. The database management system (DBMS) as claimed in any of the preceding claims wherein,
if the database query received is not the DML query, or a range table list comprises more than one table, the database query received is executed by the normal executor; or
if the database query received is the DML query, or a range table list comprises one table, the database query received is executed by the slim executor.

6. The database management system (DBMS) as claimed in any of the preceding claims wherein,
if the scan node is present in the execution plan generated by the query compiler, and if a qualification list and a target list are not simple, the database query received is executed by the normal executor; or
if the scan node is present in the execution plan generated by the query compiler, and if a qualification list and a target list are simple, the database query received is executed by the slim executor.

7. The database management system (DBMS) as claimed in any of the preceding claims wherein,
if the scan node is present, and if a query expression have sub-queries or function call except static function calls, the database query received is executed by the normal executor; or
if the scan node is present, and if a query expression does not have sub-queries or function call except static function calls, the database query received is executed by the slim executor.

8. The database management system (DBMS) as claimed in any of the preceding claims wherein, if the database query received comprises joining or aggregation or sorting, or other operations on the tuples, then comprises a top node to perform the operations, wherein if the top node is present, the database query received is executed by the normal executor.

9. The database management system (DBMS) as claimed in any of the preceding claims wherein, if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node, wherein:
if the modify table node comprises one sub node which is a result node, the database query received is executed by the slim executor; or
if the modify table node comprises more than one sub node, the database query received is executed by the normal executor.

10. The database management system (DBMS) as claimed in any of the preceding claims wherein, if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node, wherein:
if the modify table node comprises one node and the one node is a result node having at least one complex expression, the database query received is executed by the normal executor; or
if the modify table node comprises one node and the one node is a result node does not have a complex expression, the database query received is executed by the slim executor.

11. A device (200) configured to receive at least one database query for storing data in at least one database (108), and/or providing an access to the data in response to the database query received, the device (200) comprising:
a processor (202) coupled to a memory (206) wherein the memory (206) configured to store the database (108) and to store a plurality of instructions to store the data and/or provide access to the data in the database (108) in response to the database query received;
at least one query compiler (109) configured to prepare an execution plan in a tree structure, with a plurality of plan nodes, for the database query received, and
CHARACTERIZED BY COMPRISING:
an identifier module (110) configured to analyze the execution plan to categorize the database query received into simple database query or complex database query, wherein the identifier module categorizes the database query based on presence of at least one of joins clause, or data manipulation language (DML) syntax elements, or a range table list, or based on the plan node, or any combination thereof; and
at least two query executors for the execution of the the database query categorized, received from the identifier module (110), wherein at least one query executor (normal executor) (112) from the two query executors is configured to execute the complex query, and at least one other query executor (slim executor) (114) from the two query executors is configured to execute the simple query.

12. The device as claimed in claim 11, wherein the at least one other query executor (slim executor) comprises:
a node processing module configured to:
process at least one plan node received in the execution plan generated by the query compiler, wherein the plan nodes at the bottom level are table scan nodes and configured to fetch at least one tuple (raw rows) from at least one table using an access layer;
identify a requirement of slots, and/or expression contexts and thereby calls an associated module of the slots, and/or the expression contexts for allocation and management.
an executor state management module configured to:
create an executor state, wherein the executor state comprises information required by the node processing module, selected from a memory context for execution, an external parameter passed to query by a user;
manage execution information and an executor context; and
stores at least one parameter bind to the database query received.
an expression management module configured to:
evaluate expression work, wherein the expression work evaluation comprises a target list evaluation(projection) and qualification check;
a slot management module configured to:
manage at least on slot configured to store at least on tuple information, wherein the tuple information is selected from at least one of forms of tuple i.e., raw tuple, or deformed tuple, or tuple descriptor, or any combination thereof.

13. The device as claimed in claim 11, wherein the at least one query executor (normal executor) executes the complex query in a conventional query execution manner.

14. The device as claimed in claim 11, wherein the at least one other query executor (slim executor) executes the database query received, if the database query comprises at least one of single table on which the operations selected from select, or update, or insert, or delete, or having no join clause, or any combination thereof is/are to be performed.

15. The device as claimed in any of the preceding claims wherein,
if the database query received is not the DML query, or a range table list comprises more than one table, the database query received is executed by the normal executor; or
if the database query received is the DML query, or a range table list comprises one table, the database query received is executed by the slim executor.

16. The device as claimed in any of the preceding claims wherein,
if the scan node is present in the execution plan generated by the query compiler, and if a qualification list and a target list are not simple, the database query received is executed by the normal executor; or
if the scan node is present in the execution plan generated by the query compiler, and if a qualification list and a target list are simple, the database query received is executed by the slim executor.

17. The device as claimed in any of the preceding claims wherein,
if the scan node is present, and if a query expression have sub-queries or function call except static function calls, the database query received is executed by the normal executor; or
if the scan node is present, and if a query expression does not have sub-queries or function call except static function calls, the database query received is executed by the slim executor.

18. The device as claimed in any of the preceding claims wherein, if the database query received comprises joining or aggregation or sorting, or other operations on the tuples, then comprises a top node to perform the operations, wherein if the top node is present, the database query received is executed by the normal executor.

19. The device as claimed in any of the preceding claims wherein, if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node, wherein:
if the modify table node comprises one sub node which is a result node, the database query received is executed by the slim executor; or
if the modify table node comprises more than one sub node, the database query received is executed by the normal executor.

20. The device as claimed in any of the preceding claims wherein, if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node, wherein:
if the modify table node comprises one node and the one node is a result node having at least one complex expression, the database query received is executed by the normal executor; or
if the modify table node comprises one node and the one node is a result node does not have a complex expression, the database query received is executed by the slim executor.

21. A method for executing at least one database query received from a user for storing data in at least one database (108), and/or providing an access to the data from the database (108) in response to the database query received, the method comprising:
preparing (704), by means of at least one query compiler, an execution plan in a tree structure, with a plurality of plan nodes, for the database query received;
analyzing (706), by means of an identifier module, the execution plan to categorize the database query received into simple database query or complex database query, wherein the identifier module categorizes the database query based on presence of at least one of joins clause, or data manipulation language (DML) syntax elements, or a range table list, or based on the plan node, or any combination thereof;
executing (710, 712), by means of at least one query executor (normal executor) or at least one other query executor (slim executor) from at least two query executors, the database query categorized, received from the identifier module;
wherein the at least one query executor (normal executor) from the two query executors is configured to execute the complex query, and the at least one other query executor (slim executor) from the two query executors is configured to execute the simple query.

22. The method as claimed in claim 21, comprises executing the complex query, by means of the at least one query executor (normal executor), in a conventional query execution manner.

23. The method as claimed in claim 21, comprises executing, by means of the at least one other query executor (slim executor), if the database query received comprises at least one of single table on which the operations selected from select, or update, or insert, or delete, or having no join clause, or any combination thereof is/are to be performed.

24. The method as claimed in any of the preceding claims, comprises:
processing, by means of a node processing module in at least one other query executor (slim executor), at least one plan node received in the execution plan generated by the query compiler, wherein the plan nodes at the bottom level are table scan nodes and configured to fetch at least one tuple (raw rows) from at least one table using an access layer;
identifying, by means of the node processing module in the at least one other query executor (slim executor), a requirement of slots, and/or expression contexts and thereby calls an associated module of the slots, and/or the expression contexts for allocation and management;
creating, by means of an executor state management module in the at least one other query executor (slim executor), an executor state, wherein the executor state comprises information required by the node processing module, selected from a memory context for execution, an external parameter passed to query by a user;
managing, by means of the executor state management module in the at least one other query executor (slim executor), an execution information and an executor context;
storing, by means of the executor state management module in the at least one other query executor (slim executor), at least one parameter bind to the database query received;
evaluating, by means of an expression management module in the at least one other query executor (slim executor), expression work, wherein the expression work evaluation comprises a target list evaluation(projection) and qualification check;
managing, by means of a slot management module in the at least one other query executor (slim executor), at least on slot configured to store at least on tuple information, wherein the tuple information is selected from at least one of forms of tuple i.e., raw tuple, or deformed tuple, or tuple descriptor, or any combination thereof.

25. The method as claimed in any of the preceding claims, comprises:
if the database query received is not the DML query, or a range table list comprises more than one table, the database query received is executed by the normal executor; or
if the database query received is the DML query, or a range table list comprises one table, the database query received is executed by the slim executor.

26. The method as claimed in any of the preceding claims, comprises:
if the scan node is present in the execution plan generated by the query compiler, and if a qualification list and a target list are not simple, the database query received is executed by the normal executor; or
if the scan node is present in the execution plan generated by the query compiler, and if a qualification list and a target list are simple, the database query received is executed by the slim executor.

27. The method as claimed in any of the preceding claims, comprises:
if the scan node is present, and if a query expression have sub-queries or function call except static function calls, the database query received is executed by the normal executor; or
if the scan node is present, and if a query expression does not have sub-queries or function call except static function calls, the database query received is executed by the slim executor.

28. The method as claimed in any of the preceding claims comprises if the database query received comprises joining or aggregation or sorting, or other operations on the tuples, then comprises a top node to perform the operations, wherein if the top node is present, the database query received is executed by the normal executor.

29. The method as claimed in any of the preceding claims comprises: if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node, wherein:
if the modify table node comprises one sub node which is a result node, the database query received is executed by the slim executor; or
if the modify table node comprises more than one sub node, the database query received is executed by the normal executor.

30. The method as claimed in any of the preceding claims, comprises:
if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node, wherein:
if the modify table node comprises one node and the one node is a result node having at least one complex expression, the database query received is executed by the normal executor; or
if the modify table node comprises one node and the one node is a result node does not have a complex expression, the database query received is executed by the slim executor.

31. A device (200) configured to receive at least one database query for storing data in at least one database (108), and/or providing an access to the data in response to the database query received, the device (200) comprising:
a processor (202) coupled to a memory (206);
at least one query compiler (109) configured to prepare an execution plan in a tree structure, with a plurality of plan nodes, for the database query received; and
the memory (206) comprises at least two query executors, at least one query executor (normal executor) (112) and at least one other query executor (slim executor) (114), for the execution of the the database query received; and
the processor (202) executes:
an identifier module (110), stored in the memory, configured to analyze the execution plan to categorize the database query received into simple database query or complex database query, wherein the identifier module categorizes the database query based on presence of at least one of joins clause, or data manipulation language (DML) syntax elements, or a range table list, or based on the plan node, or any combination thereof; and
the at least one other query executor (slim executor) (114) comprises:
a node processing module (302), configured to:
process at least one plan node received in the execution plan generated by the query compiler, wherein the plan nodes at the bottom level are table scan nodes and configured to fetch at least one tuple (raw rows) from at least one table using an access layer;
identify a requirement of slots, and/or expression contexts and thereby calls an associated module of the slots, and/or the expression contexts for allocation and management.
an executor state management module (304), configured to:
create an executor state, wherein the executor state comprises information required by the node processing module, selected from a memory context for execution, an external parameter passed to query by a user;;
manage execution information and an executor context; and
stores at least one parameter bind to the database query received.
an expression management module (306), configured to:
evaluate expression work, wherein the expression work evaluation comprises a target list evaluation(projection) and qualification check;
a slot management module (308), configured to:
manage at least on slot configured to store at least on tuple information, wherein the tuple information is selected from at least one of forms of tuple i.e. raw tuple, or deformed tuple, or tuple descriptor, or any combination thereof;
WHEREIN, the at least one query executor (normal executor) from the two query executors is configured to execute the complex query, and at least one other query executor (slim executor) from the two query executors is configured to execute the simple query by using the node processing module, executor state management module, the expression management module, and the slot management module.
,TagSPECI:
TECHNIAL FIELD

The present subject matter described herein, in general, relates to relational database management systems, and more particularly to a system and a device comprising two different executors and a method thereof for the execution of database queries.

BACKGROUND

Structured query language (SQL) is a kind of database query and programming language which is used to store, retrieve and query the data held in the relational database system.

The sequential query language’s (SQL) development began in 1974, proposed by Boyce and Chamberlin, at that time called SEQUEL; In 1976, IBM Corporation's Sanjase research institute when developed RDBMS SYSTEM R changes SQL; ORACLE Corporation published first in 1979 based on the SQL commercialization RDBMS product; American country Standardization organization ANSI in 1986 announced that SQL takes the database industrial standard. It is well known that the SQL language contains 4 parts:
• Data definition language (DDL), contains CREATE, DROP, ALTER.
• Data manipulation language (DML) contains INSERT, UPDATE and DELETE.
• Data Query language (DQL), contains SELECT.
• Data management language (DCL) contains SQL statements such as GRANT, REVOKE, COMMIT, and ROLLBACK.

Any SQL statement is processed by the RDBMS in the following steps:
1. Parse (Syntax Check): It parses the SQL statement syntax and decides whether it conform to the standard
2. Analyze: It checks whether the objects (tables, columns, etc.) used in SQL statement exist in Database. This phase will extract any bind variable if there are any.
3. Optimize: It chooses the best plan for query execution based on cost.
4. Execute: It executes the best plan generates in previous step and returns the result.

During query execution process, for executing any SQL query, a query execution plan is generated, and after which an executor / a generic executor is invoked for the execution of the query based on the plan generated. Generally, the executors are very generic to support wide range of queries (multi node queries) that may include but not limited to Joins, Grouping, Sub queries, Triggers, Function execution in SQL, and the like. Further, the executors must have a very strong memory management system, which contains multiple memory contexts for plurality of nodes for flowing or storing the tuples in the database. A person skilled in the art may understand that when any executor is written for supporting all kind of queries then it is referred to as a generic executor, more specifically it means that the executor is not specific to handle only few queries.

Typically, there is only one executor/ a generic executor present in the existing query execution or a database system which is responsible for handling the execution of all types of queries (include the above mentioned operations). Generally, normal executors are designed to support wide range of queries, like single table query, Join queries, queries which have function access in condition, but not limited to them.

However, even though if the query is very simple and has only one node still it uses the generic executor available in the system. The time consumed in the generic executor and for the memory allocation is very huge. The time consumed in the executors is ~ 50% of the total query time. Further, for supporting all ranges of queries, the normal executor is designed very generically so that it supports all kinds of queries, hence put lot of infrastructure for supporting complex queries, and the same infrastructure is used by simple queries even though they do not need it, as there is a common executor. Furthermore, it is obvious to the person skilled in that art that, for the execution of simple queries it requires less time in executors for processing and less overall time of query execution, whereas for the execution of complex queries it takes more time in executors for processing and involves considerably huge overall time.

Hence the major challenge in the existing / traditional query execution process is how to categorize the database query into simple queries and complex queries. Currently there exists no solution in the prior-art that categorizes the database query into simple and complex query and further handles the simple and complex queries, as conventionally they are executed by a generic executor. Hence, the second major challenge is to provide separate executors for the execution of simple query and the complex query which will reduce the query execution and the overall time of the execution process.
SUMMARY

This summary is provided to introduce concepts related to dual executor system, device and method for execution of database queries and the concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.

TECHNICAL PROBLEM: The time consumed in the executors for the execution of queries is ~ 50% of the total query time. For the execution of simple queries it requires less time in executors for processing and less overall time of query execution, whereas for the execution of complex queries it takes more time in executors for processing and involves considerably huge overall time. However, due to a common executor used for the execution of simple (single node) and complex (multi-node) queries, the time required in the executors is almost same. The major challenge is how to categorize the database query into simple queries and complex queries. Further, the second major challenge is to provide separate executors for the execution of simple query and the complex query which will reduce the query execution and the overall time of the execution process. Accordingly, the time and cost of CPU also increases and the efficiency of the overall system decreases.

TECHNICAL SOLUTION: For solving the above mentioned problems and the other problems available in the prior-art a new concept of “Dual Executors” is provided in which the presence of two executors i.e., "Normal Executor" and a new light weight executor called as a “Slim Executor” is provided. The present invention also provides a mechanism to categorize the database queries into simple database query and complex database query. If query is very simple then it will bypass the "Normal Executor" and will use a "Slim Executor” otherwise it uses normal executor.

The present invention provides have a filter module called an Identifier module, which is configured to analyze the database query received and based on the execution plan generated by the query compiler decide if query is simple. If the query is simple the identifier module then pass the simple query to slim executor, and slim executor have very light weight infrastructure as it just need to support specific type of simple queries that may include operations like single table select, update, insert, delete, no join, but not limited to them.

To improve the overall performance of CPU during query execution by categorizing the database queries into simple and complex and by providing two separate query executors for the execution of database query, embodiments of the present invention provide a plurality of aspects of the present application. The plurality of aspects provides dual executor system, device and method for execution of database queries. The technical solutions are as follows:

In one aspect, a database management system (DBMS) communicably coupled to at least one database server configured to receive at least one database query from at least one database client system for storing data in at least one database of the database server, and/or providing the database client system access to the data in response to the database query received is disclosed. The database management system (DBMS) comprises of at least one query compiler configured to prepare an execution plan in a tree structure, with a plurality of plan nodes, for the database query received. Further, the database management system (DBMS) comprises of an identifier module configured to analyze the execution plan to categorize the database query received into simple database query or complex database query, wherein the identifier module categorizes the database query based on presence of at least one of joins clause, or data manipulation language (DML) syntax elements, or a range table list, or based on the plan node, or any combination thereof. The database management system (DBMS) further comprises at least two query executors for the execution of the database query categorized, received from the identifier module, wherein at least one query executor (normal executor) from the two query executors is configured to execute the complex query, and at least one other query executor (slim executor) from the two query executors is configured to execute the simple query.

In another aspect, a device configured to receive at least one database query for storing data in at least one database, and/or providing an access to the data in response to the database query received is disclosed. The device comprises of a processor coupled to a memory wherein the memory configured to store the database and to store a plurality of instructions to store the data and/or provide access to the data in the database in response to the database query received, and at least one query compiler configured to prepare an execution plan in a tree structure, with a plurality of plan nodes, for the database query received. The device further comprises of an identifier module configured to analyze the execution plan to categorize the database query received into simple database query or complex database query, wherein the identifier module categorizes the database query based on presence of at least one of joins clause, or data manipulation language (DML) syntax elements, or a range table list, or based on the plan node, or any combination thereof. The device further comprises of at least two query executors for the execution of the database query categorized, received from the identifier module, wherein at least one query executor (normal executor) from the two query executors is configured to execute the complex query, and at least one other query executor (slim executor) from the two query executors is configured to execute the simple query.

In another aspect, a device configured to receive at least one database query for storing data in at least one database, and/or providing an access to the data in response to the database query received is disclosed. The device comprises of a processor coupled to a memory, at least one query compiler configured to prepare an execution plan in a tree structure, with a plurality of plan nodes, for the database query received, and the memory comprises at least two query executors, at least one query executor (normal executor) and at least one other query executor (slim executor), for the execution of the database query received. The memory is coupled to the processor for executing at least one of the modules present in the memory, the plurality of modules include an identifier module configured to analyze the execution plan to categorize the database query received into simple database query or complex database query, wherein the identifier module categorizes the database query based on presence of at least one of joins clause, or data manipulation language (DML) syntax elements, or a range table list, or based on the plan node, or any combination thereof;. The memory also includes a node processing module configured to process at least one plan node received in the execution plan generated by the query compiler, wherein the plan nodes at the bottom level are table scan nodes and configured to fetch at least one tuple (raw rows) from at least one table using an access layer, and identify a requirement of slots, and/or expression contexts and thereby calls an associated module of the slots, and/or the expression contexts for allocation and management. The memory also includes an executor state management module configured to create an executor state, manage execution information and an executor context, and stores at least one parameter bind to the database query received. The memory also includes an expression management module configured to evaluate expression work, wherein the expression work evaluation comprises a target list evaluation (projection) and qualification check. The memory also includes a slot management module configured to manage at least on slot configured to store at least on tuple information, wherein the tuple information is selected from at least one of forms of tuple i.e. raw tuple, or deformed tuple, or tuple descriptor, or any combination thereof. The at least one query executor (normal executor) from the two query executors is configured to execute the complex query, and at least one other query executor (slim executor) from the two query executors is configured to execute the simple query by using the node processing module, executor state management module, the expression management module, and the slot management module.

In yet another aspect, a method for executing at least one database query received from a user for storing data in at least one database, and/or providing an access to the data from the database in response to the database query received is disclosed. The method includes:
• preparing, by means of at least one query compiler, an execution plan in a tree structure, with a plurality of plan nodes, for the database query received;
• analyzing, by means of an identifier module, the execution plan to categorize the database query received into simple database query or complex database query, wherein the identifier module categorizes the database query based on presence of at least one of joins clause, or data manipulation language (DML) syntax elements, or a range table list, or based on the plan node, or any combination thereof;
• executing, by means of at least one query executor (normal executor) or at least one other query executor (slim executor) from at least two query executors, the database query categorized, received from the identifier module;
wherein the at least one query executor (normal executor) from the two query executors is configured to execute the complex query, and the at least one other query executor (slim executor) from the two query executors is configured to execute the simple query.

In one implementation, the at least one query executor (normal executor) executes the complex query in a conventional query execution manner. The complex queries may include but not limited to the queries having multi-node query operations, Joins, Joins, Grouping, Sub queries, Triggers, Function execution in SQL, and the like.

In one implementation, the at least one other query executor (slim executor) executes the database query received, if the database query comprises at least one of single table on which the operations selected from select, or update, or insert, or delete, or having no join clause, or any combination thereof is/are to be performed.

In one implementation, the present invention provides a slim executor which is configured to handle only specific simple queries.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like features and components.

Figure 1 illustrates a database management system (DBMS) communicably coupled to at least one database server configured to receive at least one database query from at least one database client system for storing data in at least one database of the database server, and/or providing the database client system access to the data in response to the database query received, the database management system (DBMS) comprising at least one query compiler configured to prepare an execution plan in a tree structure, with a plurality of plan nodes, for the database query received, in accordance with an embodiment of the present subject matter.

Figure 2 illustrates a device (200) configured to receive at least one database query for storing data in at least one database (108), and/or providing an access to the data in response to the database query received, in accordance with an embodiment of the present subject matter.

Figure 3 illustrates a device (200) configured to receive at least one database query for storing data in at least one database (108), and/or providing an access to the data in response to the database query received,, in accordance with an embodiment of the present subject matter.

Figure 4 (a) and Figure 4 (b) illustrates a modular view of the slim executor, in accordance with an embodiment of the present subject matter.

Figure 5 illustrates a query execution flow, in accordance with an embodiment of the present subject matter.

Figure 6 illustrates an identifier module flow for executor selection, in accordance with an embodiment of the present subject matter.

Figure 7 illustrates a method for executing at least one database query received from a user for storing data in at least one database (108), and/or providing an access to the data from the database (108) in response to the database query received, in accordance with an embodiment of the present subject matter.

DETAILED DESCRIPTION OF THE PRESENT INVNENTION

The following clearly describes the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are merely a part rather than all of the embodiments of the present invention. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

Systems and devices with dual executors and methods for execution of database queries are disclosed.

It may be understood by the person skilled in that art that, choosing a right plan to match the query structure and the properties of the data is absolutely critical for good performance, so the system includes a complex planner that tries to select good plans. The structure of a query plan is a tree of plan nodes. Nodes at the bottom level are table scan nodes: they return raw rows (tuples) from a table. There are different types of scan nodes for different table access methods: sequential scans, index scans, and bitmap index scans. If the query requires joining, aggregation, sorting, or other operations on the raw rows, then there will be additional nodes "a top" the scan nodes to perform these operations. Again, there is usually more than one possible way to do these operations, so different node types can appear here too. The output of EXPLAIN has one line for each node in the plan tree, showing the basic node type plus the cost estimates that the planner made for the execution of that plan node. The first line (topmost node) has the estimated total execution cost for the plan; it is this number that the planner seeks to minimize.

Further, it may also be understood by the person skilled in the art that the query processing happens in three phases, parsing, planning and execution (also, as disclosed in the background of the present invention).

In one implementation, the present invention provides a new concept of “Dual Executor” in which "Normal Executor" and a Light Weight Executor which is referred to as “Slim Executor” coexists.

In one implementation, after the planning phase an identifier module (110) as disclosed in the present invention decides whether query is simple or complex based on the plan received from the query compilers. If the query is simple query it will call slim executor otherwise it will call normal executor for plan execution.

In one implementation, the identifier module specifically provided for the slim executor. The main purpose of this module is to analyze the plan tree and find whether query is simple enough so that it can be executed by slim executor or not.

In one implementation, all simple queries categorized by the identifier module are passed to the slim executor for the execution. The slim executor executes the query and sends the result to destination, and/or may store the result for future reference.

While aspects are described for execution of the queries (using dual executors) may be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary systems, devices, and methods.

Referring now to figure 1 illustrates a database management system (DBMS) communicably coupled to at least one database server configured to receive at least one database query from at least one database client system for storing data in at least one database of the database server, and/or providing the database client system access to the data in response to the database query received, the database management system (DBMS) comprising at least one query compiler configured to prepare an execution plan in a tree structure, with a plurality of plan nodes, for the database query received, in accordance with an embodiment of the present subject matter.

In one implementation, the DBMS (104) is communicably coupled with the user devices / database client systems (102) and the database server / server (106). Although the present subject matter is explained considering that the DBMS (104) is implemented as a separate computing unit it may be understood that the DBMS (104) may also be implemented on a server, in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, and the like. It will be understood that the DBMS (104) may be accessed by multiple users through one or more user devices/client systems 102-1, 102-2…102-N, collectively referred to as user 102 hereinafter, or applications residing on the user devices 102. Examples of the user devices 102 may include, but are not limited to, a portable computer, a personal digital assistant, a handheld device, and a workstation. The user devices 102 are communicatively coupled to the DBMS (104) through a network (not shown) which is further coupled to the database server (106).

In one implementation, the network may be a wireless network, a wired network or a combination thereof. The network can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further the network may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.

In one implementation the user (102) interacts with the DBMS (104) by sending/firing a query to the database (108) located at the database server (106).

In one implementation, the DBMS system (104) comprises of an identifier module (110) configured to analyze the execution plan to categorize the database query received into simple database query or complex database query, wherein the identifier module categorizes the database query based on presence of at least one of joins clause, or data manipulation language (DML) syntax elements, or a range table list, or based on the plan node, or any combination thereof.

In one implementation, the DBMS system (104) comprises at least two query executors for the execution of the the database query categorized, received from the identifier module, wherein at least one query executor (normal executor) (112) from the two query executors is configured to execute the complex query, and at least one other query executor (slim executor) (114) from the two query executors is configured to execute the simple query.

The main task of the identifier module is to analyze the query execution plan generated by the query compiler and categorize the query received into the simple query and the complex query. If the query is categorized as the simple query, this query is passed to the slim executor for the execution or else if the query is categorized as complex query it is passed to the normal executor for the execution in generic manner.

Referring now to figure 2 illustrates a device (200) configured to receive at least one database query for storing data in at least one database (108), and/or providing an access to the data in response to the database query received, in accordance with an embodiment of the present subject matter.

In one implementation, the device (200) may include at least one processor (202), an interface (204), and a memory (206). The at least one processor (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor (202) is configured to fetch and execute computer-readable instructions stored in the memory (206).

The interface (204) may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The interface (204) may allow the client systems/users (102) to interact with a user directly or through the client devices (200). Further, the interface (204) may enable the device (200) to communicate with other computing devices, such as web servers and external data servers (not shown). The interface (204) can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The interface (204) may include one or more ports for connecting a number of devices to one another or to another server.

The memory (206) may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory (206) may include at least one query compiler (109) configured to prepare an execution plan in a tree structure, with a plurality of plan nodes, for the database query received. It shall be noted that the query compiler (109) is a conventional compiler and the execution plan generation done in the tradition / convention approaches as available in the prior-art.

In one implementation, the memory (206) includes an identifier module (110) configured to analyze the execution plan to categorize the database query received into simple database query or complex database query, wherein the identifier module categorizes the database query based on presence of at least one of joins clause, or data manipulation language (DML) syntax elements, or a range table list, or based on the plan node, or any combination thereof.

In one implementation, the memory (206) includes at least two query executors for the execution of the database query categorized, received from the identifier module (110), wherein at least one query executor (normal executor) (112) from the two query executors is configured to execute the complex query, and at least one other query executor (slim executor) (114) from the two query executors is configured to execute the simple query.

The main task of the identifier module is to analyze the query execution plan generated by the query compiler and categorize the query received into the simple query and the complex query. If the query is categorized as the simple query, this query is passed to the slim executor for the execution or else if the query is categorized as complex query it is passed to the normal executor for the execution in generic manner.

Referring now to figure 3 illustrates a device (200) configured to receive at least one database query for storing data in at least one database (108), and/or providing an access to the data in response to the database query received, in accordance with an embodiment of the present subject matter.

In one implementation, the device (200) may include at least one processor (202), an interface (204), and a memory (206). The details of the memory (206), processor (202), and the interface (204) are same as explained above and hence not repeated herein. However, as shown in figure 3, the slim executor (114) comprises of a node processing module, an executor state management module, an expression management module, and a slot management module.

In one implementation, the at least one query executor (normal executor) executes the complex query in a conventional query execution manner.

In one implementation, the at least one other query executor (slim executor) executes the database query received, if the database query comprises at least one of single table on which the operations selected from select, or update, or insert, or delete, or having no join clause, or any combination thereof is/are to be performed.

In one implementation, the node processing module is configured to process at least one plan node received in the execution plan generated by the query compiler, wherein the plan nodes at the bottom level are table scan nodes and configured to fetch at least one tuple (raw rows) from at least one table using an access layer. Further, the node processing module identifies a requirement of slots, and/or expression contexts and thereby calls an associated module of the slots, and/or the expression contexts for allocation and management.

In one implementation, the executor state management module is configured to create an executor state, manage execution information and an executor context; and stores at least one parameter bind to the database query received. In one implementation, the executor state comprises information required by the node processing module, selected from a memory context for execution, an external parameter passed to query by a user

In one implementation, the expression management module is configured to evaluate expression work, wherein the expression work evaluation comprises a target list creation, qualification projections, and the like.

In one implementation, the slot management module is configured to manage at least on slot configured to store at least on tuple information, wherein the tuple information is selected from at least one of forms of tuple i.e. raw tuple, or deformed tuple, or tuple descriptor, or any combination thereof.

In one implementation, if the database query received is not the DML query, or a range table list comprises more than one table, the database query received is executed by the normal executor, or if the database query received is the DML query, or a range table list comprises one table, the database query received is executed by the slim executor.

In one implementation, if the scan node is present in the execution plan generated by the query compiler, and if a qualification list and a target list are not simple, the database query received is executed by the normal executor, or if the scan node is present in the execution plan generated by the query compiler, and if a qualification list and a target list are simple, the database query received is executed by the slim executor.

In one implementation, if the scan node is present, and if a query expression have sub-queries or function call except static function calls, the database query received is executed by the normal executor, or if the scan node is present, and if a query expression does not have sub-queries or function call except static function calls, the database query received is executed by the slim executor.

In one implementation, if the database query received comprises joining or aggregation or sorting, or other operations on the tuples, then comprises a top node to perform the operations, wherein if the top node is present, the database query received is executed by the normal executor.

In one implementation, if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node. Further, if the modify table node comprises one sub node which is a result node, the database query received is executed by the slim executor, or if the modify table node comprises more than one sub node, the database query received is executed by the normal executor.

In one implementation, if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node. Further, if the modify table node comprises one node and the one node is a result node having at least one complex expression, the database query received is executed by the normal executor, or if the modify table node comprises one node and the one node is a result node does not have a complex expression, the database query received is executed by the slim executor.

In one implementation, it may be understood by the person skilled in the art that, the invention or the technical advancement in the present invention is achieved by the providing dual/two executors i.e., the normal executor and the slim executor. Further, the advancement is also achieved by providing the identifier module which analyzes the query execution plan that may be generated by the query compiler, and based on which it categorizes the query into simple query or the complex query. After categorizing the query, the identifier passes the query to slim executor (if the query is simple) or to the normal executor (if the query is complex). Hence, the presence of two executors efficiently executes the query and the overall performance of the query execution and CPU are increased.

The various criteria’s to categorize the query into simple and complex are already explained above. However, the person skilled in the art may understand that the criteria may be changed based on the user requirement. The normal executors may be a conventional executor which executes the query in the normal/regular/generic manner.

Referring now to figure 4 (a) and figure 4 (b) illustrates a modular view of the slim executor, in accordance with an embodiment of the present subject matter.

In one implementation, as shown in the figure 4 (a), the query compiler provides the query execution plan as an input to the identifier module (110). The identifier module (110) analyzes the query plan/query and categorizes the query into either simple query or complex query.

In one implementation, if the query is categorized as the complex query i.e., if the query is multi-node query and has operations involving more than one table. The identifier module passes the complex query to the normal executor which further executes the query in generic / normal manner as known conventionally.

In one implementation, if the query is categorized as the simple query i.e., if the query is single node and has operations like insert, delete, update, modify, involving operations on only one table. The identifier module passes the simple query to the slim executor which further executes the query.

In one implementation, the slim executor comprises of a node processing module, an executor state management module, an expression management module, and a slot management module.

In one implementation, the node processing module is the central unit responsible for processing the plan node. This node is responsible for fetching the tuple using Access layer. This node will identify the requirement of slots, expression contexts and calls the respective modules for allocation and managements.

In one implementation, the executor state management module is operating when the executor is accessed first time it will create the executor state, this module further manage various execution information and executor context. This module create the memory context for executor, this context life line is till the execution finishes. This module will hold the parameter binds to the query.

In one implementation, the expression management module is responsible for all expression evaluation work, i.e. target list, qualifications projections etc. In one implementation, the expression evaluation may include a target list evaluation (projection) and qualification check.

In one implementation, the slot management module is responsible to manage the slots, in executor slots are used for storing tuple information i.e., various forms of tuple i.e. Raw tuple, deformed tuple and tuple descriptor. As part of slim executor there will be only one local slot which will hold the current tuple.

In one implementation, as shown in the figure 4 (b),various modules involved in the slim executor along with their interconnectivity is shown.

In one implementation, the node processing module is the central module and all other modules are support modules. The executor state management module is responsible for creating and managing the executor state. The executor state holds the information required by node processing module, such as, memory context for execution, external parameter passed to query by use, and the like. The slot management module is used by node processing module for storing and extracting tuple. The expression management module deals with the various expressions, like comparison, and the like.

Referring now to figure 5 illustrates a query execution flow, in accordance with an embodiment of the present subject matter. Figure 5 is the sequence diagram explaining the typical query processing in dual executor system for ad-hoc queries. The flow execution is same as above explained above, except instead of calling prepare client directly call execute with the query, this plan is generated only for once and not stored in cache.

Figure 6 illustrates an identifier module flow for executor selection, in accordance with an embodiment of the present subject matter. In one implementation, the flowchart provided in figure 6 explains how the identifier module (110) processes the plan and decide whether the query is simple or not.

In one implementation, if the database query received is not the DML query, or a range table list comprises more than one table, the database query received is executed by the normal executor, or if the database query received is the DML query, or a range table list comprises one table, the database query received is executed by the slim executor.

In one implementation, if the scan node is present in the execution plan generated by the query compiler, and if a qualification list and a target list are not simple, the database query received is executed by the normal executor, or if the scan node is present in the execution plan generated by the query compiler, and if a qualification list and a target list are simple, the database query received is executed by the slim executor.

In one implementation, if the scan node is present, and if a query expression have sub-queries or function call except static function calls, the database query received is executed by the normal executor, or if the scan node is present, and if a query expression does not have sub-queries or function call except static function calls, the database query received is executed by the slim executor.

In one implementation, if the database query received comprises joining or aggregation or sorting, or other operations on the tuples, then comprises a top node to perform the operations, wherein if the top node is present, the database query received is executed by the normal executor.

In one implementation, if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node. Further, if the modify table node comprises one sub node which is a result node, the database query received is executed by the slim executor, or if the modify table node comprises more than one sub node, the database query received is executed by the normal executor.

In one implementation, if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node. Further, if the modify table node comprises one node and the one node is a result node having at least one complex expression, the database query received is executed by the normal executor, or if the modify table node comprises one node and the one node is a result node does not have a complex expression, the database query received is executed by the slim executor.

In one implementation, below mentioned are few types (but not only limited to them) of queries that are supported by slim Executor:
When planner will hand over the plan to the Identifier module:
• If query is not DML or Range table list has more than one table it goes to normal executor.
• If plan includes a scan node (sequence scan or index Scan) then it should have very simple target list expression and qualification list (Any expression should not have any sub-queries or function call except static function calls).
• If not a scan node then it will be insert/update/delete operation so a top node will be Modify Table Node.
? Modify table should have only one sub node and that must be result Node.
? Result node target list should not have any complex expressions.

Figure 7 illustrates a method for executing at least one database query received from a user for storing data in at least one database (108), and/or providing an access to the data from the database (108) in response to the database query received, in accordance with an embodiment of the present subject matter. The method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.

The order in which the method is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method or alternate methods. Additionally, individual blocks may be deleted from the method without departing from the scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method may be considered to be implemented in the above described DBMS (104) and/or device (200).

At block 702, the database query is received. In one implementation, the database query may be fired by the user.

At block 704, the database query execution plan is prepared. In one implementation, the database query received is passed to the query compiler for the preparation of the execution plan. It may be noted that the query compiler is any of the conventionally know compilers which are used in planner phase of conventional query processing mechanisms.

At block 706, the execution plan prepared by the query compiler in earlier step is received by and analyzed to categorize the database query received into simple database query or the complex database query. In one implementation, the categorization of the database query is performed by the identifier module (110) in similar manner as explained above.

At block 708, the query categorized into simple and complex query is passed to the respective executor. In one implementation, if the identifier module is configured to categorize and pass the query to the respective executors. If the query is complex query it is passed to the normal executor, and if the query is simple query it is passed to the slim executor.

At block 710, the simple query received by the slim executor is executed in the manner explained above using the node processing module, the executor state management module, the expression management module, and the slot management module.

At block 712, the complex query received by the normal executor is executed in conventional manner.

At block 714, the result is displayed to the user and/or stored for the future reference.

In one implementation, the method comprises executing the complex query, by means of the at least one query executor (normal executor), in a conventional query execution manner.

In one implementation, the method comprises executing, by means of the at least one other query executor (slim executor), if the database query received comprises at least one of single table on which the operations selected from select, or update, or insert, or delete, or having no join clause, or any combination thereof is/are to be performed.

In one implementation, the method comprises
• processing, by means of a node processing module in at least one other query executor (slim executor), at least one plan node received in the execution plan generated by the query compiler, wherein the plan nodes at the bottom level are table scan nodes and configured to fetch at least one tuple (raw rows) from at least one table using an access layer;
• identifying, by means of the node processing module in the at least one other query executor (slim executor), a requirement of slots, and/or expression contexts and thereby calls an associated module of the slots, and/or the expression contexts for allocation and management;
• creating, by means of an executor state management module in the at least one other query executor (slim executor), an executor state;
• managing, by means of the executor state management module in the at least one other query executor (slim executor), an execution information and an executor context;
• storing, by means of the executor state management module in the at least one other query executor (slim executor), at least one parameter bind to the database query received;
• evaluating, by means of an expression management module in the at least one other query executor (slim executor), expression work, wherein the expression work evaluation comprises a target list evaluation(projection) and qualification check.
• managing, by means of a slot management module in the at least one other query executor (slim executor), at least on slot configured to store at least on tuple information, wherein the tuple information is selected from at least one of forms of tuple i.e., raw tuple, or deformed tuple, or tuple descriptor, or any combination thereof.

In one implementation, if the database query received comprises joining or aggregation or sorting, or other operations on the tuples, then comprises a top node to perform the operations, wherein if the top node is present, the database query received is executed by the normal executor.

In one implementation, if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node. Further, if the modify table node comprises one sub node which is a result node, the database query received is executed by the slim executor; or if the modify table node comprises more than one sub node, the database query received is executed by the normal executor.

In one implementation, if the database query received comprises at least one on insert operation or delete operation, or update operations, the top node is a modify table node. Further, if the modify table node comprises one node and the one node is a result node having at least one complex expression, the database query received is executed by the normal executor; or if the modify table node comprises one node and the one node is a result node does not have a complex expression, the database query received is executed by the slim executor.

Exemplary embodiments discussed above may provide certain advantages. Though not required to practice aspects of the disclosure, these advantages may include:
1. The performance of simple SQL queries will increase in case of OLTP where most of the queries will be simple.
2. Dual executor provides a fast execution of simple queries using Light Weight Executor and also supports wide range of queries using generic executor.
3. The database system with two executors “Light Weight Executor” and “Generic Executor” coexists.
4. On planning time itself planner is capable of deciding whether a query is simple or not, if simple it will take the light weight executor path else it will take generic executor path.

Although implementations for dual executor system, device and method for execution of database queries have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations for dual executor system, device and method for execution of database queries.