CA2249096C - Method for determining optimal database materializations using a query optimizer - Google Patents
Method for determining optimal database materializations using a query optimizer Download PDFInfo
- Publication number
- CA2249096C CA2249096C CA002249096A CA2249096A CA2249096C CA 2249096 C CA2249096 C CA 2249096C CA 002249096 A CA002249096 A CA 002249096A CA 2249096 A CA2249096 A CA 2249096A CA 2249096 C CA2249096 C CA 2249096C
- Authority
- CA
- Canada
- Prior art keywords
- materializations
- query
- temporary
- execution plans
- query execution
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24539—Query rewriting; Transformation using cached or materialised query results
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99932—Access augmentation or optimizing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99934—Query formulation, input preparation, or translation
Abstract
A method for determining optimal database materializations utilizing a query optimizer in a database management system. The method takes one or more queries as inputs and using the query optimizer in the database management system generates a series of virtual materializations by materializing some subsets of the database. The virtual materializations are used to consider the relative performance benefits, i.e. cost-benefits, for the queries based on the various virtual materializations. If the query optimizer decides to use any of the materializations in its plan, then those materializations are recommended to the user, or created automatically for the user.
Description
- I -TITLE: METHOD FOR DETERMINING OPTIMAL DATABASE
MATERIALIZATIONS USING A QUERY OPTIMIZER
FIELD OF THE INVENTION
The present invention relates to database management systems and more particularly to a method for determining optimal database materializations utilizing a query optimizer.
BACKGROUND OF THE INVENTION
A database management system (DBMS) comprises the combination of an appropriate computer, direct access storage devices (DASD) or disk drives, and database management software. A relational database management system is a DBMS
which uses relational techniques for storing and retrieving information. The relational database management system or RDBMS comprises computerized information storage and retrieval systems in which data is stored on disk drives or DASD for semi-permanent storage. The data is stored in the form of tables which comprise rows and columns. Each row or tuple has one or more columns.
The R.DBMS is designed to accept commands to store, retrieve, and delete data. One widely used and well known set of commands is based on the Structured Query Language or SQL.
The term query refers to a set of commands in SQL for retrieving data from the RDBMS. The definitions of SQL
provide that a RDBMS should respond to a particular query with " CA 02249096 1998-09-30
MATERIALIZATIONS USING A QUERY OPTIMIZER
FIELD OF THE INVENTION
The present invention relates to database management systems and more particularly to a method for determining optimal database materializations utilizing a query optimizer.
BACKGROUND OF THE INVENTION
A database management system (DBMS) comprises the combination of an appropriate computer, direct access storage devices (DASD) or disk drives, and database management software. A relational database management system is a DBMS
which uses relational techniques for storing and retrieving information. The relational database management system or RDBMS comprises computerized information storage and retrieval systems in which data is stored on disk drives or DASD for semi-permanent storage. The data is stored in the form of tables which comprise rows and columns. Each row or tuple has one or more columns.
The R.DBMS is designed to accept commands to store, retrieve, and delete data. One widely used and well known set of commands is based on the Structured Query Language or SQL.
The term query refers to a set of commands in SQL for retrieving data from the RDBMS. The definitions of SQL
provide that a RDBMS should respond to a particular query with " CA 02249096 1998-09-30
- 2 -a particular set of data given a specified database content.
SQL however does not specify the actual method to find the requested information in the tables on the disk drives. There are many ways in which a query can be processed and each consumes a different amount of processor and input/output access time. The method in which the query is processed, i.e.
query execution plan, affects the overall time for retrieving the data. The time taken to retrieve data can be critical to the operation of the database. It is therefore important to select a method for finding the data requested in a query which minimizes the computer and disk access time, and therefore, optimizing the cost of doing the query.
A database system user retrieves data from the database by entering requests or queries into the database.
The RDBMS interprets the user's query and then determines how best to go about retrieving the requested data. In order to achieve this, the RDBMS has a component called the query optimizer. The RDBMS uses the query optimizer to analyze how to best conduct the user's query of the database with optimum speed in accessing the database being the primary factor. The query optimizer takes the query and generates a query execution plan. The query execution plan comprises a translation of the user's SQL commands in terms of the RDBMS
operators. There may be several alternative query execution plans generated by the query optimizer, each specifying a set of operations to be executed by the RDBMS. The many query execution plans generated for a single query ultimately differ in their total cost of obtaining the desired data. The query optimizer then evaluates these cost estimates for each query execution plan in order to determine which plan has the lowest ~
SQL however does not specify the actual method to find the requested information in the tables on the disk drives. There are many ways in which a query can be processed and each consumes a different amount of processor and input/output access time. The method in which the query is processed, i.e.
query execution plan, affects the overall time for retrieving the data. The time taken to retrieve data can be critical to the operation of the database. It is therefore important to select a method for finding the data requested in a query which minimizes the computer and disk access time, and therefore, optimizing the cost of doing the query.
A database system user retrieves data from the database by entering requests or queries into the database.
The RDBMS interprets the user's query and then determines how best to go about retrieving the requested data. In order to achieve this, the RDBMS has a component called the query optimizer. The RDBMS uses the query optimizer to analyze how to best conduct the user's query of the database with optimum speed in accessing the database being the primary factor. The query optimizer takes the query and generates a query execution plan. The query execution plan comprises a translation of the user's SQL commands in terms of the RDBMS
operators. There may be several alternative query execution plans generated by the query optimizer, each specifying a set of operations to be executed by the RDBMS. The many query execution plans generated for a single query ultimately differ in their total cost of obtaining the desired data. The query optimizer then evaluates these cost estimates for each query execution plan in order to determine which plan has the lowest ~
- 3 -execution cost. In order to determine a query execution plan with the lowest execution cost, the query optimizer uses specific combinations of operations to collect and retrieve the desired data. When a query execution plan is finally selected and executed, the data requested by the user is retrieved according to that specific query execution plan however manipulated or rearranged.
In a SQL based RDBMS the query execution plan comprises a set of primitive operations or commands, e.g.
JOIN; a sequence in which the retrieve operations will be executed, a . g . JOIN ORDER; a specif is method f or performing the operation, e.g. SORT-MERGE JOIN; or an access method to obtain records from the base relations, e.g. INDEX SCAN. In most database systems, particularly large institutional systems, a cost-based query optimizer will be utilized_ A
cost-based query optimizer uses estimates of I/O and CPU
resource consumption in determining the most efficient query execution plan because both I/O and CPU resource consumption depend on the number of rows that need to be processed.
The performance of queries against a database may be enhanced significantly by materializing certain data that may be redundant of data already in the database. This materialized data may be organized in ways better suited to certain database operations, such as searching for specific data, for example as with indexes, or may pre-compute information likely to be asked for often, as with materialized views, for example.
' CA 02249096 1998-09-30 _ 4 -Data materialization such as indexes can benefit performance of a query in one or-more of the following ways.
First, a materialization can be used to rapidly find data which satisfies a user-specified search criterion, for example, predicates specified in the WHERE clause of an SQL
query. Second, a materialization can be used to access rows in a particular order, thereby saving sort operations to achieve that ordering for operations such as JOINS or GROUP BY
or ORDER BY clauses specified by the user. Thirdly, a materialization can be used to provide a subset of a table's columns, or tables' in the case of join indexes, that are a superset of the columns requested in a user query, thereby saving the access of the data pages of the base table.
Because the data pages in the base table are presumably much larger than the index pages in the index table, the cost per row is greater for the base table.
On the other hand, materialized data has additional costs which include the following: (1) update costs to keep the materialization consistent with other data that has been modified, requiring possible data access and computation to determine the new contents of the materialized data based upon what data was modified; (2) storage costs for the materialized data, which is usually redundant of the base data; (3) increased optimization time to consider the use of these materializations, as an alternative to, or in addition to, accessing the base table.
Currently, most database systems leave the determination of the appropriate materializations up to the user. However, this can be very difficult and/or time-consuming for the user. There are typically numerous possible materializations and in many possible combinations.
Furthermore, the costs and benefits of each combination will, in general, be very difficult for the user to assess.
Accordingly the present invention provides a method for determining optimal database materializations using a query optimizer.
BRIEF SUMMARY OF THE INVENTION
The present invention provides a method for exploiting a database query optimizer to recommend materializations, for example indexes, of a database to enhance performance. The method takes one or more queries as inputs and using the cost-based optimizer in the database management system generates a series of virtual materializations by materializing some subsets of the database. The virtual materializations are used to consider the relative performance benefits, i.e. cost-benefits, for the queries based on the various virtual materializations. If the optimizer decides to use any of the materializations in its plan, then those materializations are recommended to the user, or created automatically for the user.
A feature of the present invention is that the method is incorporated into the query optimizer, rather than as an external tool. This arrangement provides the following advantages: (1) The existing infrastructure for iterating through alternative access paths to a table, and for estimating execution costs of these alternatives, can be ' CA 02249096 1998-09-30 exploited, and do not have to be replicated in an external tool. (2) Maintenance costs decrease because the equations used to estimate costs and benefits need be maintained in only one place, i.e. in the query optimizer. (3) There is greater accuracy in cost estimation, since there is no possibility of the query optimizer and an external tool being out of synchronization. The user is also guaranteed that the query optimizer will use the recommended materialization if it is defined, since the query optimizer recommended the materialization by using its equations to pick that materialization for use. (4) There is greater efficiency in determining the materializations to recommend, since the query optimizer need only be invoked once to determine the best materializations for a given query. An external tool, on the other hand, must iteratively recommend and create candidate materializations and invoke the query optimizer to assess that set of materializations.
In one aspect, the present invention provides a method for determining optimal materializations for a query optimizer in a database management system, wherein the query optimizer generates one or more query execution plans in response to a query input from a user for accessing data in a database schema in the database management system, the method comprises the steps of: (a) generating a plurality of temporary materializations as candidates for the query execution plans associated with the query; (b) computing estimated statistics for selected performance parameters for each of the temporary materializations; (c) utilizing the query optimizer to optimize each of the query execution plans;
(d) determining if any of the temporary materializations are CA9-9$-037 being utilized in any of the query execution plans; (e) if any of the temporary materializations are being utilized in any of the query execution plans, recommending the temporary materializations to the user together with the associated query execution plans.
In another aspect, the present invention provides a relational database management system for use with a computer system wherein queries are entered by a user for retrieving data from a database schema, the relational database IO management system includes a query optimizer for optimizing query execution plans associated with the queries entered by the user, the system comprises: (a) means for processing queries; (b) means for generating a plurality of temporary materializations as candidates for the query execution plans associated with the query; (c) means for computing estimated statistics for selected performance parameters for each of the temporary materializations; (d) the query optimizer including means for optimizing each of-the query execution plans and means for selecting query execution plans on the basis of selected performance parameters; (e) means for determining if any temporary materializations are being utilized in any of the query execution plans; (f) means for recommending the temporary materializations to the user together with the associated query execution plans selected by the query optimizer if any of the temporary materializations are being utilized in one of the query execution plans.
In yet another aspect, the present invention provides a computer program product for use on a computer wherein queries are entered by a user for retrieving data from - g _ a relational database management system having a query optimizer for optimizing query execution plans associated with the queries entered by the user, the computer program product comprises: a recording medium; means recorded on the medium for instructing the computer to perform the steps of, (a) generating a plurality of temporary materializations as candidates for the query execution plans associated with the query; (b) computing estimated statistics for selected performance parameters for each of the temporary materializations; (c) utilizing the query optimizer to optimize each of the query execution plans; (d) determining if any of the temporary materializations are being utilized in any of the query execution plans; (e) if any of the temporary materializations are being utilized in any of the query execution plans, recommending the temporary materializations to the user together with the associated query execution plans.
BRIEF DESCRIPTION OF THE DRAWINGS
Reference will now be made to the accompanying drawings which show, by way of example, preferred embodiments of the present invention, and in which:
Fig. 1 shows in diagrammatic form a database management system incorporating a method or process according to the present invention for determining optimal database materializations using a query optimizer;
_ g Fig. 2 is a flow chart showing a method according to the present invention for determining optimal database materializations using a query optimizer;
Fig. 3 shows in schematic form an example executed according to the method of Fig. 1.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Reference is first made to Fig. l, which shows in schematic form a database management system 10 incorporating a method or process 100 according to the present invention for determining optimal database materializations using a query optimizer 15. The processing steps embodied in the method for determining optimal database materializations are shown in Fig. 2 as will be described below.
As shown in Fig. 1, the database management system (DBMS) 10 comprises the combination of an appropriate central processing unit 11 (i.e. a computer), direct access storage devices (DASD) or disk drives 12, and database management software 13. A relational database management system 10 is a DBMS which uses relational techniques for storing and retrieving information. The relational database management system or RDBMS 10 comprises computerized information storage and retrieval systems in which data is stored on the DASD 12 or disk drives for semi-permanent storage. The data is stored in the form of a database schema or schema 19 which comprises one or more tables 20, shown individually as 20a, 20b,...20n.
Each table 20 comprise rows and columns, with each row or tuple having one or more columns.
As shown in Fig . 1 , the database management sof tware 13 includes an SQL engine 14 and a query optimizer denoted generally by 15. The SQL engine 14 is a software module which performs the operations specified by the queries. An SQL
statement that performs an operation on a database is termed a query. The query optimizer 15 uses conventional techniques to evaluate the most cost-effective way (i.e. query execution plan) for retrieving data from the database schema 19 in response to the user's query and in accordance with the present invention, the query optimizer 15 incorporates a method or process 100 for determining optimal database materializations. The SQL engine 14 together with the query optimizer 15 perform the operations specified by the queries and generate virtual materializations 24 and materialized views 26 which are stored in the storage media 12. In the context of the present invention, a virtual materialization 24 is a compilation of information which is generated by the method 100 according to the present invention as will be described below. A materialized view 26 is also a compilation of information, similar in structure to a table, and is the result of query which has been optimized according to the present invention. The materialized views 26 are stored in the storage media 12 and in known manner are usable as an input to a query to the database management system 10 DBMS or RDBMS.
The query definitions are stored on the storage media 12 and comprise one or more queries 22 shown individually as 22a, 22b,...22m. Each query 22 specifies a series of operations that are to be performed on one or more of the tables 20 in the database. The queries 22 are typically written in SQL. The virtual materialized views 24 comprise one or more virtual materialized views, shown individually as 24a, 24b,...24x, which are generated by the method 100 in response to the queries. The materialized views 26, shown individually as 26a, 26b,...26y, each comprise a compilation of information, and stored in the storage media 12. As will be described in more detail below, the materialized views 26 are derived from the virtual materializations 24, and a subsequent query is executed with one or more of the materialized views 26, or on a combination of materialized views 26 and tables 20.
As will now be described, the method according to the present invention provides a mechanism for extending the query optimizer 15 to recommend beneficial materializations 26 of data based upon the cost equations already defined for a query optimizer. This is achieved by generating virtual materializations 24 and using the existing cost estimation equations in the query optimizer 15 to assess the cost and benefits of multiple, alternative materializations. Referring to Fig. 2, the method 100 according to the present invention comprises the following processing steps.
The first processing step denoted by 101 is conducted before a query optimization is performed for a given query to the database 19. The first processing step 101 comprises generating one or more virtual materializations 24 (Fig. 1) which might benefit the execution of the particular query as will now be described with reference to the following three examples.
. CA 02249096 1998-09-30 In Example 1, virtual materializations are generated for all possible indexes which may be used to access data from the database, e.g. in response to a INDEX SCAN SQL command in the user's query.
Example #1 - exhaustive enumeration of all possible indexes For each table T in the schema For each combination C of the columns in table T
Generate a new virtual index on table T corresponding to the combination of columns C
In Example 2, virtual materializations are generated for all possible join materializations, e.g. in response to a JOIN SQL command in the user's query.
Example #2 - Exhaustive enumeration of all possible join materializations For N = 2 to n (i.e. number of tables in query) For each possible combination C of N tables using all possible 2 0 tables Generate a new virtual materialization corresponding to the join of the tables in combination C
In Example 3, virtual materializations are generated for selected enumerations.
Example #3 - selective enumeration To reduce the search space, a more selective enumeration algorithm is used.
If the query optimizer knows which are the "interesting columns" and the "interesting orders" and the "interesting bounding predicates"
or start/stop keys, then an enumerator generates virtual indexes which contain just the interesting columns and orders or the indexes that would benefit from the bounding predicates or start/stop keys.
The second processing step 102 comprises computing estimated statistics for the virtual materializations 24 generated in step 101, as if the virtual materializations 24 where actual materializations. The estimated statistics are computed using the query optimizer 15 as will be described in more detail below.
The third step 103 in the method 100 comprises optimizing the SQL queries using the query optimizer 15 for the database management system 10. The SQL queries 22 (Fig.
1) are typically optimized in workloads where each workload comprises a group of SQL queries_ This step involves using the existing optimization algorithm in the query optimizer 15.
It will be appreciated that the query optimizer 15 must be extended so that groups of SQL queries, i.e. workloads, can be optimized instead of only a single query. Such an optimizer 15 is known as a Masa Query Optimizer as will be familiar to those skilled in the art. The optimization algorithm in the query optimizer 15 considers alternative access paths or query execution plans, including the virtual materializations (e. g.
indexes) , and estimates the cost benefit to query execution of each access path. The query optimizer 15 then picks the "optimal", i.e. least cost plan, including in that consideration all "virtual" materializations 24, as well as the actual materialized views 26.
Reference is made to Fig. 3, which shows the optimization of an exemplary workload, WORKLOAD 1. The cost of WORKLOAD1 is equal to the sum of the cost of each query, Q1, Q2 and Q3, multiplied by their associated weights, W1, W2 and W3, respectively. The weights W1, W2, W3 are typically the expected frequency of each query Q1, Q2, Q3. In this example, a virtual materialization 24 for a new index to Table R has been generated according to the first step 101 of the method 100 (Fig. 2) The workload optimizer 15 optimizes for minimum overall cost of the complete workload, in order to evaluate the usefulness of any virtual materialization 24 and materialized views 26. For example, the new index on Table R
will make Query 2 go faster because the SORT operation is then eliminated for the second query Q2. However, this same index on Table R will slow down performance of the third query Q3 because the insert into Table R will require an update of this new index. As a result, the optimizer 15 chooses whether the virtual materialization 24 for the index is cost-effective based on the weights associated with the second query Q2 and the third query Q3.
If the "optimal" plan utilizes any "virtual"
materializations, then the plan cannot be executed until those materializations are actually created, i.e. converted into corresponding materialized views 26_ The virtual materializations can be used to recommend to the user that they be created, or can be used to automatically materialize the recommended materializations. Accordingly, the next step 104 in the method 100 as shown in Fig. 2 comprises determining if any virtual materializations 24 were selected by the query optimizer 15 for the query execution plans. If the query optimizer 15 did not select any of the virtual materializations 24, then the virtual materializations 24 are removed from the storage media I2 (Fig. 1) as shown in step 105 in Fig. 2. On the other hand, if the query optimizer 15 has selected a query execution plan which incorporates one or more of the virtual materializations 24, then the virtual materializations 24 are recommended to the user together with the associated query execution plan as shown in step 106 in Fig. 2. For the example shown in Fig. 3, the execution plan for the second query Q2 utilizes a virtual materialization for the index to Table R.
As described above, step 103 of the method 100 includes the process of optimizing for minimum total workload cost. The process of optimizing utilizes the virtual materializations 24 (Fig. 1) which were generated in step 101 and may be further refined as follows:
(1) The existing optimization algorithm in the query optimizer 15 applies conventional techniques in the consideration of alternative access paths or query execution plans, including indexes, and estimates the respective cost-benefit of each access path to query execution, and picks the "optimal", i.e. least cost, access path or query execution plan. In the evaluation of the alternative access paths or query execution plans, the optimization algorithm considers all the virtual materializations 24 as well as the actual materialized views 26.
(2) The existing optimization algorithm applies conventional techniques in the consideration of alternative access paths or query execution plans, including indexes, and estimates the respective cost-benefit of each access path to query execution, and picks the "optimal" or least cost access path or query execution plan. In the evaluation, the optimization algorithm only considers the actual materialized views 26.
The estimated benefit of the virtual materializations 24 is given as the difference in cost of the access plan chosen by the optimizer in (1) as described above and the access plan chosen by the optimizer in (2) as also described above.
A feature of the present invention is that the method is incorporated into the query optimizer, rather than as an external tool. This arrangement provides the following advantages:
(1) The existing infrastructure for iterating through alternative access paths to a table, and for estimating execution costs of these alternatives, can be exploited, and does not have to be replicated in an external tool_ (2) Maintenance costs decrease because the equations used to estimate costs and benefits need be maintained in only one place, i.e. in the query optimizer.
(3) There is greater accuracy in cost estimation, since there is no possibility of the query optimizer and an external tool being out of synchronization. The user is also guaranteed that the query optimizer will use the recommended materialization if it is defined, since the query optimizer recommended the materialization by using its equations to pick that materialization for use.
In a SQL based RDBMS the query execution plan comprises a set of primitive operations or commands, e.g.
JOIN; a sequence in which the retrieve operations will be executed, a . g . JOIN ORDER; a specif is method f or performing the operation, e.g. SORT-MERGE JOIN; or an access method to obtain records from the base relations, e.g. INDEX SCAN. In most database systems, particularly large institutional systems, a cost-based query optimizer will be utilized_ A
cost-based query optimizer uses estimates of I/O and CPU
resource consumption in determining the most efficient query execution plan because both I/O and CPU resource consumption depend on the number of rows that need to be processed.
The performance of queries against a database may be enhanced significantly by materializing certain data that may be redundant of data already in the database. This materialized data may be organized in ways better suited to certain database operations, such as searching for specific data, for example as with indexes, or may pre-compute information likely to be asked for often, as with materialized views, for example.
' CA 02249096 1998-09-30 _ 4 -Data materialization such as indexes can benefit performance of a query in one or-more of the following ways.
First, a materialization can be used to rapidly find data which satisfies a user-specified search criterion, for example, predicates specified in the WHERE clause of an SQL
query. Second, a materialization can be used to access rows in a particular order, thereby saving sort operations to achieve that ordering for operations such as JOINS or GROUP BY
or ORDER BY clauses specified by the user. Thirdly, a materialization can be used to provide a subset of a table's columns, or tables' in the case of join indexes, that are a superset of the columns requested in a user query, thereby saving the access of the data pages of the base table.
Because the data pages in the base table are presumably much larger than the index pages in the index table, the cost per row is greater for the base table.
On the other hand, materialized data has additional costs which include the following: (1) update costs to keep the materialization consistent with other data that has been modified, requiring possible data access and computation to determine the new contents of the materialized data based upon what data was modified; (2) storage costs for the materialized data, which is usually redundant of the base data; (3) increased optimization time to consider the use of these materializations, as an alternative to, or in addition to, accessing the base table.
Currently, most database systems leave the determination of the appropriate materializations up to the user. However, this can be very difficult and/or time-consuming for the user. There are typically numerous possible materializations and in many possible combinations.
Furthermore, the costs and benefits of each combination will, in general, be very difficult for the user to assess.
Accordingly the present invention provides a method for determining optimal database materializations using a query optimizer.
BRIEF SUMMARY OF THE INVENTION
The present invention provides a method for exploiting a database query optimizer to recommend materializations, for example indexes, of a database to enhance performance. The method takes one or more queries as inputs and using the cost-based optimizer in the database management system generates a series of virtual materializations by materializing some subsets of the database. The virtual materializations are used to consider the relative performance benefits, i.e. cost-benefits, for the queries based on the various virtual materializations. If the optimizer decides to use any of the materializations in its plan, then those materializations are recommended to the user, or created automatically for the user.
A feature of the present invention is that the method is incorporated into the query optimizer, rather than as an external tool. This arrangement provides the following advantages: (1) The existing infrastructure for iterating through alternative access paths to a table, and for estimating execution costs of these alternatives, can be ' CA 02249096 1998-09-30 exploited, and do not have to be replicated in an external tool. (2) Maintenance costs decrease because the equations used to estimate costs and benefits need be maintained in only one place, i.e. in the query optimizer. (3) There is greater accuracy in cost estimation, since there is no possibility of the query optimizer and an external tool being out of synchronization. The user is also guaranteed that the query optimizer will use the recommended materialization if it is defined, since the query optimizer recommended the materialization by using its equations to pick that materialization for use. (4) There is greater efficiency in determining the materializations to recommend, since the query optimizer need only be invoked once to determine the best materializations for a given query. An external tool, on the other hand, must iteratively recommend and create candidate materializations and invoke the query optimizer to assess that set of materializations.
In one aspect, the present invention provides a method for determining optimal materializations for a query optimizer in a database management system, wherein the query optimizer generates one or more query execution plans in response to a query input from a user for accessing data in a database schema in the database management system, the method comprises the steps of: (a) generating a plurality of temporary materializations as candidates for the query execution plans associated with the query; (b) computing estimated statistics for selected performance parameters for each of the temporary materializations; (c) utilizing the query optimizer to optimize each of the query execution plans;
(d) determining if any of the temporary materializations are CA9-9$-037 being utilized in any of the query execution plans; (e) if any of the temporary materializations are being utilized in any of the query execution plans, recommending the temporary materializations to the user together with the associated query execution plans.
In another aspect, the present invention provides a relational database management system for use with a computer system wherein queries are entered by a user for retrieving data from a database schema, the relational database IO management system includes a query optimizer for optimizing query execution plans associated with the queries entered by the user, the system comprises: (a) means for processing queries; (b) means for generating a plurality of temporary materializations as candidates for the query execution plans associated with the query; (c) means for computing estimated statistics for selected performance parameters for each of the temporary materializations; (d) the query optimizer including means for optimizing each of-the query execution plans and means for selecting query execution plans on the basis of selected performance parameters; (e) means for determining if any temporary materializations are being utilized in any of the query execution plans; (f) means for recommending the temporary materializations to the user together with the associated query execution plans selected by the query optimizer if any of the temporary materializations are being utilized in one of the query execution plans.
In yet another aspect, the present invention provides a computer program product for use on a computer wherein queries are entered by a user for retrieving data from - g _ a relational database management system having a query optimizer for optimizing query execution plans associated with the queries entered by the user, the computer program product comprises: a recording medium; means recorded on the medium for instructing the computer to perform the steps of, (a) generating a plurality of temporary materializations as candidates for the query execution plans associated with the query; (b) computing estimated statistics for selected performance parameters for each of the temporary materializations; (c) utilizing the query optimizer to optimize each of the query execution plans; (d) determining if any of the temporary materializations are being utilized in any of the query execution plans; (e) if any of the temporary materializations are being utilized in any of the query execution plans, recommending the temporary materializations to the user together with the associated query execution plans.
BRIEF DESCRIPTION OF THE DRAWINGS
Reference will now be made to the accompanying drawings which show, by way of example, preferred embodiments of the present invention, and in which:
Fig. 1 shows in diagrammatic form a database management system incorporating a method or process according to the present invention for determining optimal database materializations using a query optimizer;
_ g Fig. 2 is a flow chart showing a method according to the present invention for determining optimal database materializations using a query optimizer;
Fig. 3 shows in schematic form an example executed according to the method of Fig. 1.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Reference is first made to Fig. l, which shows in schematic form a database management system 10 incorporating a method or process 100 according to the present invention for determining optimal database materializations using a query optimizer 15. The processing steps embodied in the method for determining optimal database materializations are shown in Fig. 2 as will be described below.
As shown in Fig. 1, the database management system (DBMS) 10 comprises the combination of an appropriate central processing unit 11 (i.e. a computer), direct access storage devices (DASD) or disk drives 12, and database management software 13. A relational database management system 10 is a DBMS which uses relational techniques for storing and retrieving information. The relational database management system or RDBMS 10 comprises computerized information storage and retrieval systems in which data is stored on the DASD 12 or disk drives for semi-permanent storage. The data is stored in the form of a database schema or schema 19 which comprises one or more tables 20, shown individually as 20a, 20b,...20n.
Each table 20 comprise rows and columns, with each row or tuple having one or more columns.
As shown in Fig . 1 , the database management sof tware 13 includes an SQL engine 14 and a query optimizer denoted generally by 15. The SQL engine 14 is a software module which performs the operations specified by the queries. An SQL
statement that performs an operation on a database is termed a query. The query optimizer 15 uses conventional techniques to evaluate the most cost-effective way (i.e. query execution plan) for retrieving data from the database schema 19 in response to the user's query and in accordance with the present invention, the query optimizer 15 incorporates a method or process 100 for determining optimal database materializations. The SQL engine 14 together with the query optimizer 15 perform the operations specified by the queries and generate virtual materializations 24 and materialized views 26 which are stored in the storage media 12. In the context of the present invention, a virtual materialization 24 is a compilation of information which is generated by the method 100 according to the present invention as will be described below. A materialized view 26 is also a compilation of information, similar in structure to a table, and is the result of query which has been optimized according to the present invention. The materialized views 26 are stored in the storage media 12 and in known manner are usable as an input to a query to the database management system 10 DBMS or RDBMS.
The query definitions are stored on the storage media 12 and comprise one or more queries 22 shown individually as 22a, 22b,...22m. Each query 22 specifies a series of operations that are to be performed on one or more of the tables 20 in the database. The queries 22 are typically written in SQL. The virtual materialized views 24 comprise one or more virtual materialized views, shown individually as 24a, 24b,...24x, which are generated by the method 100 in response to the queries. The materialized views 26, shown individually as 26a, 26b,...26y, each comprise a compilation of information, and stored in the storage media 12. As will be described in more detail below, the materialized views 26 are derived from the virtual materializations 24, and a subsequent query is executed with one or more of the materialized views 26, or on a combination of materialized views 26 and tables 20.
As will now be described, the method according to the present invention provides a mechanism for extending the query optimizer 15 to recommend beneficial materializations 26 of data based upon the cost equations already defined for a query optimizer. This is achieved by generating virtual materializations 24 and using the existing cost estimation equations in the query optimizer 15 to assess the cost and benefits of multiple, alternative materializations. Referring to Fig. 2, the method 100 according to the present invention comprises the following processing steps.
The first processing step denoted by 101 is conducted before a query optimization is performed for a given query to the database 19. The first processing step 101 comprises generating one or more virtual materializations 24 (Fig. 1) which might benefit the execution of the particular query as will now be described with reference to the following three examples.
. CA 02249096 1998-09-30 In Example 1, virtual materializations are generated for all possible indexes which may be used to access data from the database, e.g. in response to a INDEX SCAN SQL command in the user's query.
Example #1 - exhaustive enumeration of all possible indexes For each table T in the schema For each combination C of the columns in table T
Generate a new virtual index on table T corresponding to the combination of columns C
In Example 2, virtual materializations are generated for all possible join materializations, e.g. in response to a JOIN SQL command in the user's query.
Example #2 - Exhaustive enumeration of all possible join materializations For N = 2 to n (i.e. number of tables in query) For each possible combination C of N tables using all possible 2 0 tables Generate a new virtual materialization corresponding to the join of the tables in combination C
In Example 3, virtual materializations are generated for selected enumerations.
Example #3 - selective enumeration To reduce the search space, a more selective enumeration algorithm is used.
If the query optimizer knows which are the "interesting columns" and the "interesting orders" and the "interesting bounding predicates"
or start/stop keys, then an enumerator generates virtual indexes which contain just the interesting columns and orders or the indexes that would benefit from the bounding predicates or start/stop keys.
The second processing step 102 comprises computing estimated statistics for the virtual materializations 24 generated in step 101, as if the virtual materializations 24 where actual materializations. The estimated statistics are computed using the query optimizer 15 as will be described in more detail below.
The third step 103 in the method 100 comprises optimizing the SQL queries using the query optimizer 15 for the database management system 10. The SQL queries 22 (Fig.
1) are typically optimized in workloads where each workload comprises a group of SQL queries_ This step involves using the existing optimization algorithm in the query optimizer 15.
It will be appreciated that the query optimizer 15 must be extended so that groups of SQL queries, i.e. workloads, can be optimized instead of only a single query. Such an optimizer 15 is known as a Masa Query Optimizer as will be familiar to those skilled in the art. The optimization algorithm in the query optimizer 15 considers alternative access paths or query execution plans, including the virtual materializations (e. g.
indexes) , and estimates the cost benefit to query execution of each access path. The query optimizer 15 then picks the "optimal", i.e. least cost plan, including in that consideration all "virtual" materializations 24, as well as the actual materialized views 26.
Reference is made to Fig. 3, which shows the optimization of an exemplary workload, WORKLOAD 1. The cost of WORKLOAD1 is equal to the sum of the cost of each query, Q1, Q2 and Q3, multiplied by their associated weights, W1, W2 and W3, respectively. The weights W1, W2, W3 are typically the expected frequency of each query Q1, Q2, Q3. In this example, a virtual materialization 24 for a new index to Table R has been generated according to the first step 101 of the method 100 (Fig. 2) The workload optimizer 15 optimizes for minimum overall cost of the complete workload, in order to evaluate the usefulness of any virtual materialization 24 and materialized views 26. For example, the new index on Table R
will make Query 2 go faster because the SORT operation is then eliminated for the second query Q2. However, this same index on Table R will slow down performance of the third query Q3 because the insert into Table R will require an update of this new index. As a result, the optimizer 15 chooses whether the virtual materialization 24 for the index is cost-effective based on the weights associated with the second query Q2 and the third query Q3.
If the "optimal" plan utilizes any "virtual"
materializations, then the plan cannot be executed until those materializations are actually created, i.e. converted into corresponding materialized views 26_ The virtual materializations can be used to recommend to the user that they be created, or can be used to automatically materialize the recommended materializations. Accordingly, the next step 104 in the method 100 as shown in Fig. 2 comprises determining if any virtual materializations 24 were selected by the query optimizer 15 for the query execution plans. If the query optimizer 15 did not select any of the virtual materializations 24, then the virtual materializations 24 are removed from the storage media I2 (Fig. 1) as shown in step 105 in Fig. 2. On the other hand, if the query optimizer 15 has selected a query execution plan which incorporates one or more of the virtual materializations 24, then the virtual materializations 24 are recommended to the user together with the associated query execution plan as shown in step 106 in Fig. 2. For the example shown in Fig. 3, the execution plan for the second query Q2 utilizes a virtual materialization for the index to Table R.
As described above, step 103 of the method 100 includes the process of optimizing for minimum total workload cost. The process of optimizing utilizes the virtual materializations 24 (Fig. 1) which were generated in step 101 and may be further refined as follows:
(1) The existing optimization algorithm in the query optimizer 15 applies conventional techniques in the consideration of alternative access paths or query execution plans, including indexes, and estimates the respective cost-benefit of each access path to query execution, and picks the "optimal", i.e. least cost, access path or query execution plan. In the evaluation of the alternative access paths or query execution plans, the optimization algorithm considers all the virtual materializations 24 as well as the actual materialized views 26.
(2) The existing optimization algorithm applies conventional techniques in the consideration of alternative access paths or query execution plans, including indexes, and estimates the respective cost-benefit of each access path to query execution, and picks the "optimal" or least cost access path or query execution plan. In the evaluation, the optimization algorithm only considers the actual materialized views 26.
The estimated benefit of the virtual materializations 24 is given as the difference in cost of the access plan chosen by the optimizer in (1) as described above and the access plan chosen by the optimizer in (2) as also described above.
A feature of the present invention is that the method is incorporated into the query optimizer, rather than as an external tool. This arrangement provides the following advantages:
(1) The existing infrastructure for iterating through alternative access paths to a table, and for estimating execution costs of these alternatives, can be exploited, and does not have to be replicated in an external tool_ (2) Maintenance costs decrease because the equations used to estimate costs and benefits need be maintained in only one place, i.e. in the query optimizer.
(3) There is greater accuracy in cost estimation, since there is no possibility of the query optimizer and an external tool being out of synchronization. The user is also guaranteed that the query optimizer will use the recommended materialization if it is defined, since the query optimizer recommended the materialization by using its equations to pick that materialization for use.
(4) There is greater efficiency in determining the materializations to recommend, since the query optimizer need only be invoked once to determine the best materializations for a given query. An external tool, on the other hand, must iteratively recommend and create candidate materializations and invoke the query optimizer to assess that set of materializations.
As described it is a principal feature of the present invention that the method for determining optimal database materializations utilizes the existing query optimizer 15 in the database management system 10 (Fig. 1).
An implementation of a function for generating a virtual materialization of an index using the existing query optimizer 15 may take the following form:
2 0 // within the context of the optimizer, this function is used to generate a subplan which is a scan of table T1 1: function access table(Tl) 2: generate table scan~lans(T1);
2 5 3: generate virtual indexes(T1);
4: generate index scan~lans(T1);
As described it is a principal feature of the present invention that the method for determining optimal database materializations utilizes the existing query optimizer 15 in the database management system 10 (Fig. 1).
An implementation of a function for generating a virtual materialization of an index using the existing query optimizer 15 may take the following form:
2 0 // within the context of the optimizer, this function is used to generate a subplan which is a scan of table T1 1: function access table(Tl) 2: generate table scan~lans(T1);
2 5 3: generate virtual indexes(T1);
4: generate index scan~lans(T1);
5: add new subplans to list();
6: function generate virtual indexes(T1) {
7: variable COLTJNIN SET;
8: loop (COLITNtI~7 SET=all combinations of column orders) {
9: variable INDEX;
10: INDEX=add virtual index(T1,COLiJNIN SET);
11: generate statistics(INDEX);
) The function for generating a virtual materialization of an index comprises a function access table(T1) (line 1) and a function generate virtual indexes(Tl) (line 6).
Referring to the pseudo-code listing above, the access table(Tl) function comprises a function generate table scanJplans (T1) (line 2), a function generate virtual-indexes(T1) (line 3), a function generate index scan~lans(T1) (line 4) and a function add new subplans~to list(). The function access table(T1) comprises a known function in the query optimizer 15 and as will be familiar to one skilled in the art the function is called when the query optimizer 15 needs to make a list of all possible methods of scanning table T1, including index scan.
The function generate table scan~lans(Tl) also comprises a known function in the query optimizer 15 which generates methods for scanning the table T1 without using its indexes, and proposes a subplan in each case as will understood by one skilled in the art . The function generate virtual indexes (T1 ) is a new function implemented in the query optimizer 15 which is used to add virtual indexes to the array of available indexes on table T1. The function generate index scan~lans (T1) is a known function in the query optimizer 15 which looks at the list of indexes (existing and virtual) on table T1, checks which indexes can be used to satisfy the query, and proposes a subplan in each case. The function add new subplans to list() also comprises a known function in the query optimizer 15 which takes the valid subplans and adds them to the list of all available subplans.
The specific implementation aspects of these functions in accordance with the present invention are within the understanding of one skilled in the art.
The function generate virtual indexes(T1) comprises an iterative loop (line 8) which is executed for all combinations of column orders as defined by a variable COLUMI~T SET (line 7) . In the loop, a variable INDEX (line 9) is updated by a function add virtual index (line 10) and then cost-benefit statistics are generated by a function generate statistics (line 11) for each INDEX (i.e. virtual materialization). The function add virtual-index (Tl, COLUMI~7 SET) is a new function implemented in the query optimizer 15 which effectively adds a new entry in the list of table T1 indexes, and marks each of these new entries as "virtual". The function generate statistics(INDEX) is a new function implemented in the query optimizer 15 which estimates statistics for the new INDEX, and places these statistics together with the associated INDEX. These statistics are used by the query optimizer 15 for costing, and they may be derived from the table statistics of table T1 and the subset of columns that appear in this INDEX. The specific implementation aspects of these functions in accordance with the present invention are within the understanding of one skilled in the art_ An implementation of a function for generating a virtual materialization of a JOIN using the existing query optimizer 15 in the database management system 10 of Fig. 1 may take the following form:
// within the context of the optimizer, this function is used to generate a subplan which joins two existing subplans SP1 and SP2 1: function access-join(SP1,SP2) 2: variable MATERIALIZED JOIN;
3: MATERIALIZED JOIN=generate virtual materialized join(SP1,SP2);
4: generate-join subplans(SP1,SP2);
5: generate table subplans(MATERIALIZED JOIN);
6: add new subplans-to list();
The function is defined as access join(SP1, SP2) in line 1.
The access join function includes a function generate virtual materialized join (line 3), a function generate join-subplans (SP1, SP2), a function generate table subplans (MATERIALIZED JOIN) (line 5), and a function add new subplans to list() (line 6). The function access join(SP1, SP2) is a known function in the query optimizer 15 which as will be familiar to one skilled in the art is called when the query optimizer 15 needs new subplans which represent the joining of old subplans SP1 and SP2. The . CA 02249096 1998-09-30 function access join(SP1, SP2) includes another known query optimizer function, generate join sublplans(SP1, SP2). The function generate-join subplans(SP1, SP2) as will be familiar to one skilled in the art is used to generate subplans which execute the join of SP1 and SP2 using available join techniques, e.g. nested-loop join, sort-merge join, hash join.
The function access join (SP1, SP2) also includes another known query optimizer function, generate table subplans (MATERIALIZED JOINS) which as will be familiar to one skilled in the art checks if there are any MATERIALIZED JOINS that can satisfy the requirements of j oining SP1 and SP2 . The function generate virtual materialized join(SP1, SP2) is a new function implemented in the query optimizer 15 which generates virtual materializations of the effective result of joining the tables in SP1 with the tables in SP2, and adds these materializations, along with the associated statistics, to the list of available materializations, and these new materializations are marked as "virtual". The specific implementation aspects of these functions in accordance with the present invention are within the understanding of one skilled in the art.
The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Certain adaptations and modifications of the invention will be obvious to those skilled in the art. Therefore, the presently discussed embodiments are considered to be illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein
) The function for generating a virtual materialization of an index comprises a function access table(T1) (line 1) and a function generate virtual indexes(Tl) (line 6).
Referring to the pseudo-code listing above, the access table(Tl) function comprises a function generate table scanJplans (T1) (line 2), a function generate virtual-indexes(T1) (line 3), a function generate index scan~lans(T1) (line 4) and a function add new subplans~to list(). The function access table(T1) comprises a known function in the query optimizer 15 and as will be familiar to one skilled in the art the function is called when the query optimizer 15 needs to make a list of all possible methods of scanning table T1, including index scan.
The function generate table scan~lans(Tl) also comprises a known function in the query optimizer 15 which generates methods for scanning the table T1 without using its indexes, and proposes a subplan in each case as will understood by one skilled in the art . The function generate virtual indexes (T1 ) is a new function implemented in the query optimizer 15 which is used to add virtual indexes to the array of available indexes on table T1. The function generate index scan~lans (T1) is a known function in the query optimizer 15 which looks at the list of indexes (existing and virtual) on table T1, checks which indexes can be used to satisfy the query, and proposes a subplan in each case. The function add new subplans to list() also comprises a known function in the query optimizer 15 which takes the valid subplans and adds them to the list of all available subplans.
The specific implementation aspects of these functions in accordance with the present invention are within the understanding of one skilled in the art.
The function generate virtual indexes(T1) comprises an iterative loop (line 8) which is executed for all combinations of column orders as defined by a variable COLUMI~T SET (line 7) . In the loop, a variable INDEX (line 9) is updated by a function add virtual index (line 10) and then cost-benefit statistics are generated by a function generate statistics (line 11) for each INDEX (i.e. virtual materialization). The function add virtual-index (Tl, COLUMI~7 SET) is a new function implemented in the query optimizer 15 which effectively adds a new entry in the list of table T1 indexes, and marks each of these new entries as "virtual". The function generate statistics(INDEX) is a new function implemented in the query optimizer 15 which estimates statistics for the new INDEX, and places these statistics together with the associated INDEX. These statistics are used by the query optimizer 15 for costing, and they may be derived from the table statistics of table T1 and the subset of columns that appear in this INDEX. The specific implementation aspects of these functions in accordance with the present invention are within the understanding of one skilled in the art_ An implementation of a function for generating a virtual materialization of a JOIN using the existing query optimizer 15 in the database management system 10 of Fig. 1 may take the following form:
// within the context of the optimizer, this function is used to generate a subplan which joins two existing subplans SP1 and SP2 1: function access-join(SP1,SP2) 2: variable MATERIALIZED JOIN;
3: MATERIALIZED JOIN=generate virtual materialized join(SP1,SP2);
4: generate-join subplans(SP1,SP2);
5: generate table subplans(MATERIALIZED JOIN);
6: add new subplans-to list();
The function is defined as access join(SP1, SP2) in line 1.
The access join function includes a function generate virtual materialized join (line 3), a function generate join-subplans (SP1, SP2), a function generate table subplans (MATERIALIZED JOIN) (line 5), and a function add new subplans to list() (line 6). The function access join(SP1, SP2) is a known function in the query optimizer 15 which as will be familiar to one skilled in the art is called when the query optimizer 15 needs new subplans which represent the joining of old subplans SP1 and SP2. The . CA 02249096 1998-09-30 function access join(SP1, SP2) includes another known query optimizer function, generate join sublplans(SP1, SP2). The function generate-join subplans(SP1, SP2) as will be familiar to one skilled in the art is used to generate subplans which execute the join of SP1 and SP2 using available join techniques, e.g. nested-loop join, sort-merge join, hash join.
The function access join (SP1, SP2) also includes another known query optimizer function, generate table subplans (MATERIALIZED JOINS) which as will be familiar to one skilled in the art checks if there are any MATERIALIZED JOINS that can satisfy the requirements of j oining SP1 and SP2 . The function generate virtual materialized join(SP1, SP2) is a new function implemented in the query optimizer 15 which generates virtual materializations of the effective result of joining the tables in SP1 with the tables in SP2, and adds these materializations, along with the associated statistics, to the list of available materializations, and these new materializations are marked as "virtual". The specific implementation aspects of these functions in accordance with the present invention are within the understanding of one skilled in the art.
The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Certain adaptations and modifications of the invention will be obvious to those skilled in the art. Therefore, the presently discussed embodiments are considered to be illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein
Claims (11)
1. A method for determining optimal materializations for a query optimizer in a database management system, wherein the query optimizer generates one or more query execution plans in response to a query input from a user for accessing data in a database schema in the database management system, said method comprising the steps of:
(a) generating a plurality of temporary materializations as candidates for the query execution plans associated with the query;
(b) computing estimated statistics for selected performance parameters for each of said temporary materializations;
(c) utilizing the query optimizer to optimize each of the query execution plans;
(d) determining if any of said temporary materializations are being utilized in any of the query execution plans;
(e) if any of said temporary materializations are being utilized in any of the query execution plans, recommending said temporary materializations to the user together with the associated query execution plans.
(a) generating a plurality of temporary materializations as candidates for the query execution plans associated with the query;
(b) computing estimated statistics for selected performance parameters for each of said temporary materializations;
(c) utilizing the query optimizer to optimize each of the query execution plans;
(d) determining if any of said temporary materializations are being utilized in any of the query execution plans;
(e) if any of said temporary materializations are being utilized in any of the query execution plans, recommending said temporary materializations to the user together with the associated query execution plans.
2. The method as claimed in claim 1, further including the step of deleting said temporary materializations not being utilized in any of the query execution plans.
3. The method as claimed in claim 1 or 2, further including the step of converting said recommended temporary materializations into actual materializations.
4. The method as claimed in claim 1, wherein said step of generating a plurality of temporary materializations for the query comprises generating a temporary materialization for an index which becomes a candidate for the query execution plans.
5. The method as claimed in claim 1, wherein said step of generating a plurality of temporary materializations for the query comprises generating a temporary materialization for a join index which becomes a candidate for the query execution plans.
6. The method as claimed in claim 1, wherein said step of generating a plurality of temporary materializations for the query comprises generating a temporary materialization for columns and orders of interest which becomes a candidate for the query execution plans.
7. A relational database management system for use with a computer system wherein queries are entered by a user for retrieving data from a database schema, the relational database management system including a query optimizer for optimizing query execution plans associated with the queries entered by the user, said relational database management system comprising:
(a) means for processing queries;
(b) means for generating a plurality of temporary materializations as candidates for the query execution plans associated with the query;
(c) means for computing estimated statistics for selected performance parameters for each of said temporary materializations;
(d) the query optimizer including means for optimizing each of the query execution plans and means for selecting query execution plans on the basis of selected performance parameters;
(e) means for determining if any of said temporary materializations are being utilized in any of the query execution plans;
(f) means for recommending said temporary materializations to the user together with the associated query execution plans selected by the query optimizer if any of said temporary materializations are being utilized in any of the query execution plans.
(a) means for processing queries;
(b) means for generating a plurality of temporary materializations as candidates for the query execution plans associated with the query;
(c) means for computing estimated statistics for selected performance parameters for each of said temporary materializations;
(d) the query optimizer including means for optimizing each of the query execution plans and means for selecting query execution plans on the basis of selected performance parameters;
(e) means for determining if any of said temporary materializations are being utilized in any of the query execution plans;
(f) means for recommending said temporary materializations to the user together with the associated query execution plans selected by the query optimizer if any of said temporary materializations are being utilized in any of the query execution plans.
8. The relational database management system as claimed in claim 7, further including means for deleting temporary materializations not being utilized in any of the query execution plans.
9. The relational database management system as claimed in claim 8, including means for converting said recommended temporary materializations into actual materializations.
10. A computer program product for use on a computer wherein queries are entered by a user for retrieving data from a relational database management system having a query optimizer for optimizing query execution plans associated with the queries entered by the user, said computer program product comprising:
a recording medium;
means recorded on said medium for instructing said computer to perform the steps of, (a) generating a plurality of temporary materializations as candidates for the query execution plans associated with the query;
(b) computing estimated statistics for selected performance parameters for each of said temporary materializations;
(c) utilizing the query optimizer to optimize each of the query execution plans;
(d) determining if any of said temporary materializations are being utilized in any of the query execution plans;
(e) if any of said temporary materializations are being utilized in any of the query execution plans, recommending the temporary materializations to the user together with the associated query execution plans.
a recording medium;
means recorded on said medium for instructing said computer to perform the steps of, (a) generating a plurality of temporary materializations as candidates for the query execution plans associated with the query;
(b) computing estimated statistics for selected performance parameters for each of said temporary materializations;
(c) utilizing the query optimizer to optimize each of the query execution plans;
(d) determining if any of said temporary materializations are being utilized in any of the query execution plans;
(e) if any of said temporary materializations are being utilized in any of the query execution plans, recommending the temporary materializations to the user together with the associated query execution plans.
11. A Data storage medium recorded with a computer program which, in combination with a computer configured for database management, is adapted to carry out the method of any one of claims 1, 2, 3, 4, 5 or 6.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002249096A CA2249096C (en) | 1998-09-30 | 1998-09-30 | Method for determining optimal database materializations using a query optimizer |
| US09/409,323 US6356889B1 (en) | 1998-09-30 | 1999-09-30 | Method for determining optimal database materializations using a query optimizer |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002249096A CA2249096C (en) | 1998-09-30 | 1998-09-30 | Method for determining optimal database materializations using a query optimizer |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2249096A1 CA2249096A1 (en) | 2000-03-30 |
| CA2249096C true CA2249096C (en) | 2001-12-04 |
Family
ID=4162868
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002249096A Expired - Fee Related CA2249096C (en) | 1998-09-30 | 1998-09-30 | Method for determining optimal database materializations using a query optimizer |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6356889B1 (en) |
| CA (1) | CA2249096C (en) |
Families Citing this family (73)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6529901B1 (en) * | 1999-06-29 | 2003-03-04 | Microsoft Corporation | Automating statistics management for query optimizers |
| US7461058B1 (en) * | 1999-09-24 | 2008-12-02 | Thalveg Data Flow Llc | Optimized rule based constraints for collaborative filtering systems |
| US7783625B2 (en) * | 1999-12-22 | 2010-08-24 | International Business Machines Corporation | Using data in materialized query tables as a source for query optimization statistics |
| US6778983B1 (en) * | 2000-04-28 | 2004-08-17 | International Business Machines Corporation | Apparatus and method for accessing HTML files using an SQL query |
| US7788123B1 (en) | 2000-06-23 | 2010-08-31 | Ekhaus Michael A | Method and system for high performance model-based personalization |
| US7650304B1 (en) | 2000-09-08 | 2010-01-19 | Capital One Financial Corporation | Solicitation to web marketing loop process |
| US7567916B1 (en) * | 2000-09-12 | 2009-07-28 | Capital One Financial Corporation | System and method for performing Web based in-view monitoring |
| US7287020B2 (en) * | 2001-01-12 | 2007-10-23 | Microsoft Corporation | Sampling for queries |
| JP2002259442A (en) * | 2001-02-28 | 2002-09-13 | Fujitsu Ltd | Database search method and recording medium |
| US6850933B2 (en) * | 2001-11-15 | 2005-02-01 | Microsoft Corporation | System and method for optimizing queries using materialized views and fast view matching |
| US6801905B2 (en) * | 2002-03-06 | 2004-10-05 | Sybase, Inc. | Database system providing methodology for property enforcement |
| US7111020B1 (en) * | 2002-03-26 | 2006-09-19 | Oracle International Corporation | Incremental refresh of materialized views containing rank function, and rewrite of queries containing rank or rownumber or min/max aggregate functions using such a materialized view |
| US7406469B1 (en) | 2002-06-20 | 2008-07-29 | Oracle International Corporation | Linear instance mapping for query rewrite |
| US20040193656A1 (en) * | 2003-03-28 | 2004-09-30 | Pizzo Michael J. | Systems and methods for caching and invalidating database results and derived objects |
| US7747606B2 (en) * | 2003-09-06 | 2010-06-29 | Oracle International Corporation | Automatic SQL tuning advisor |
| US7552110B2 (en) * | 2003-09-22 | 2009-06-23 | International Business Machines Corporation | Method for performing a query in a computer system to retrieve data from a database |
| US7562094B1 (en) | 2003-12-31 | 2009-07-14 | Precise Software Solutions, Inc. | Object-level database performance management |
| US7757226B2 (en) * | 2004-03-17 | 2010-07-13 | Oracle International Corporation | Method and mechanism for performing a rolling upgrade of distributed computer software |
| US7200595B2 (en) * | 2004-03-29 | 2007-04-03 | Microsoft Corporation | Systems and methods for fine grained access control of data stored in relational databases |
| US7890497B2 (en) * | 2004-04-14 | 2011-02-15 | Oracle International Corporation | Using estimated cost to schedule an order for refreshing a set of materialized views (MVS) |
| US20050234945A1 (en) * | 2004-04-14 | 2005-10-20 | Oracle International Corporation | Allocating CPU resources for a particular refresh schedule |
| US7734602B2 (en) * | 2004-04-14 | 2010-06-08 | Oracle International Corporation | Choosing whether to use a delayed index maintenance depending on the portion of the materialized view (MV) changed |
| US8478742B2 (en) * | 2004-04-14 | 2013-07-02 | Oracle Corporation | Using estimated cost to refresh a set of materialized views (MVS) |
| US20050251523A1 (en) * | 2004-05-07 | 2005-11-10 | Oracle International Corporation | Minimizing downtime for application changes in database systems |
| US7788285B2 (en) | 2004-05-14 | 2010-08-31 | Oracle International Corporation | Finer grain dependency tracking for database objects |
| US8996502B2 (en) * | 2004-05-17 | 2015-03-31 | Oracle International Corporation | Using join dependencies for refresh |
| US7797286B2 (en) * | 2004-05-21 | 2010-09-14 | Sap Ag | System and method for externally providing database optimizer statistics |
| US20050283458A1 (en) * | 2004-06-22 | 2005-12-22 | Microsoft Corporation | Automatic detection of frequently used query patterns in a query workload |
| US7599937B2 (en) * | 2004-06-28 | 2009-10-06 | Microsoft Corporation | Systems and methods for fine grained access control of data stored in relational databases |
| US7685137B2 (en) * | 2004-08-06 | 2010-03-23 | Oracle International Corporation | Technique of using XMLType tree as the type infrastructure for XML |
| US7849183B1 (en) | 2004-08-31 | 2010-12-07 | Precise Software Solutions, Inc. | Method of monitoring network and application performance by analyzing web clients and web servers |
| US8161038B2 (en) * | 2004-10-29 | 2012-04-17 | International Business Machines Corporation | Maintain optimal query performance by presenting differences between access plans |
| US7536379B2 (en) * | 2004-12-15 | 2009-05-19 | International Business Machines Corporation | Performing a multiple table join operating based on generated predicates from materialized results |
| US7359922B2 (en) * | 2004-12-22 | 2008-04-15 | Ianywhere Solutions, Inc. | Database system and methodology for generalized order optimization |
| US7447681B2 (en) | 2005-02-17 | 2008-11-04 | International Business Machines Corporation | Method, system and program for selection of database characteristics |
| US7685150B2 (en) * | 2005-04-19 | 2010-03-23 | Oracle International Corporation | Optimization of queries over XML views that are based on union all operators |
| US8166059B2 (en) | 2005-07-08 | 2012-04-24 | Oracle International Corporation | Optimization of queries on a repository based on constraints on how the data is stored in the repository |
| US7840553B2 (en) * | 2005-10-07 | 2010-11-23 | Oracle International Corp. | Recommending materialized views for queries with multiple instances of same table |
| US7634457B2 (en) * | 2005-10-07 | 2009-12-15 | Oracle International Corp. | Function-based index tuning for queries with expressions |
| US7689538B2 (en) * | 2006-01-26 | 2010-03-30 | International Business Machines Corporation | Autonomic recommendation and placement of materialized query tables for load distribution |
| US7882121B2 (en) * | 2006-01-27 | 2011-02-01 | Microsoft Corporation | Generating queries using cardinality constraints |
| US7913241B2 (en) * | 2006-06-13 | 2011-03-22 | Oracle International Corporation | Techniques of optimizing XQuery functions using actual argument type information |
| US7877373B2 (en) * | 2006-06-30 | 2011-01-25 | Oracle International Corporation | Executing alternative plans for a SQL statement |
| US7577642B2 (en) * | 2006-07-13 | 2009-08-18 | Oracle International Corporation | Techniques of XML query optimization over static and dynamic heterogeneous XML containers |
| US20080016088A1 (en) * | 2006-07-13 | 2008-01-17 | Zhen Hua Liu | Techniques of XML query optimization over dynamic heterogeneous XML containers |
| US8903801B2 (en) | 2007-09-14 | 2014-12-02 | Oracle International Corporation | Fully automated SQL tuning |
| US8341178B2 (en) * | 2007-09-18 | 2012-12-25 | Oracle International Corporation | SQL performance analyzer |
| US20090083214A1 (en) * | 2007-09-21 | 2009-03-26 | Microsoft Corporation | Keyword search over heavy-tailed data and multi-keyword queries |
| US8335767B2 (en) | 2007-10-17 | 2012-12-18 | Oracle International Corporation | Maintaining and utilizing SQL execution plan histories |
| US8150850B2 (en) * | 2008-01-07 | 2012-04-03 | Akiban Technologies, Inc. | Multiple dimensioned database architecture |
| US20090177697A1 (en) * | 2008-01-08 | 2009-07-09 | International Business Machines Corporation | Correlation and parallelism aware materialized view recommendation for heterogeneous, distributed database systems |
| US8312007B2 (en) * | 2008-05-08 | 2012-11-13 | International Business Machines Corporation | Generating database query plans |
| US9189047B2 (en) | 2008-05-08 | 2015-11-17 | International Business Machines Corporation | Organizing databases for energy efficiency |
| US7941426B2 (en) * | 2008-05-08 | 2011-05-10 | International Business Machines Corporation | Optimizing database queries |
| US7958112B2 (en) * | 2008-08-08 | 2011-06-07 | Oracle International Corporation | Interleaving query transformations for XML indexes |
| US8332388B2 (en) | 2010-06-18 | 2012-12-11 | Microsoft Corporation | Transformation rule profiling for a query optimizer |
| US9773032B2 (en) * | 2011-09-30 | 2017-09-26 | Bmc Software, Inc. | Provision of index recommendations for database access |
| US9183253B2 (en) * | 2012-06-27 | 2015-11-10 | Nec Laboratories America, Inc. | System for evolutionary analytics |
| US8996499B2 (en) | 2012-12-19 | 2015-03-31 | International Business Machines Corporation | Using temporary performance objects for enhanced query performance |
| US9298771B2 (en) * | 2013-01-30 | 2016-03-29 | Ias Solutions, Inc. | Resource estimation for a query optimization process |
| US9110949B2 (en) * | 2013-02-11 | 2015-08-18 | Oracle International Corporation | Generating estimates for query optimization |
| US9135280B2 (en) | 2013-02-11 | 2015-09-15 | Oracle International Corporation | Grouping interdependent fields |
| US9471545B2 (en) | 2013-02-11 | 2016-10-18 | Oracle International Corporation | Approximating value densities |
| US10621064B2 (en) | 2014-07-07 | 2020-04-14 | Oracle International Corporation | Proactive impact measurement of database changes on production systems |
| GB201620199D0 (en) | 2015-12-18 | 2017-01-11 | British Telecomm | Autonomic method for managing a computer system |
| US11386058B2 (en) | 2017-09-29 | 2022-07-12 | Oracle International Corporation | Rule-based autonomous database cloud service framework |
| US11327932B2 (en) | 2017-09-30 | 2022-05-10 | Oracle International Corporation | Autonomous multitenant database cloud service framework |
| US11823008B2 (en) | 2017-10-19 | 2023-11-21 | British Telecommunications Public Limited Company | Algorithm consolidation |
| GB2588638A (en) * | 2019-10-30 | 2021-05-05 | British Telecomm | A computing system |
| US11941535B2 (en) | 2019-10-30 | 2024-03-26 | British Telecommunications Public Limited Company | Computer-implemented method of modifying an algorithm operating on a computing system |
| CN111797112B (en) * | 2020-06-05 | 2022-04-01 | 武汉大学 | PostgreSQL preparation statement execution optimization method |
| US11500871B1 (en) * | 2020-10-19 | 2022-11-15 | Splunk Inc. | Systems and methods for decoupling search processing language and machine learning analytics from storage of accessed data |
| CN115630117B (en) * | 2022-12-21 | 2023-04-07 | 网易（杭州）网络有限公司 | Data analysis method, materialized view generation method and related equipment |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH022459A (en) * | 1987-12-11 | 1990-01-08 | Hewlett Packard Co <Hp> | Inquiry processing |
| CA2168287C (en) * | 1995-03-31 | 2000-05-23 | Guy M. Lohman | Method for detecting and optimizing relational queries with encoding/decoding tables |
| US5864842A (en) * | 1995-10-23 | 1999-01-26 | Ncr Corporation | Optimization of SQL queries using hash star join operations |
| US5822747A (en) * | 1996-08-23 | 1998-10-13 | Tandem Computers, Inc. | System and method for optimizing database queries |
| US5822750A (en) * | 1997-06-30 | 1998-10-13 | International Business Machines Corporation | Optimization of correlated SQL queries in a relational database management system |
| US5864840A (en) * | 1997-06-30 | 1999-01-26 | International Business Machines Corporation | Evaluation of existential and universal subquery in a relational database management system for increased efficiency |
| US6199063B1 (en) * | 1998-03-27 | 2001-03-06 | Red Brick Systems, Inc. | System and method for rewriting relational database queries |
| US6122644A (en) * | 1998-07-01 | 2000-09-19 | Microsoft Corporation | System for halloween protection in a database system |
| US6240406B1 (en) * | 1998-08-31 | 2001-05-29 | The Trustees Of The University Of Pennsylvania | System and method for optimizing queries with aggregates and collection conversions |
-
1998
- 1998-09-30 CA CA002249096A patent/CA2249096C/en not_active Expired - Fee Related
-
1999
- 1999-09-30 US US09/409,323 patent/US6356889B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CA2249096A1 (en) | 2000-03-30 |
| US6356889B1 (en) | 2002-03-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2249096C (en) | Method for determining optimal database materializations using a query optimizer | |
| CA2146171C (en) | Method for estimating cardinalities for query processing in a relational database management system | |
| Zilio et al. | Recommending materialized views and indexes with the IBM DB2 design advisor | |
| Agrawal et al. | Automated selection of materialized views and indexes in SQL databases | |
| US7080062B1 (en) | Optimizing database queries using query execution plans derived from automatic summary table determining cost based queries | |
| Babu et al. | Proactive re-optimization | |
| US8386450B2 (en) | Query optimization technique for obtaining improved cardinality estimates using statistics on pre-defined queries | |
| US5943666A (en) | Method and apparatus for optimizing queries across heterogeneous databases | |
| US7783625B2 (en) | Using data in materialized query tables as a source for query optimization statistics | |
| US8423569B2 (en) | Decomposed query conditions | |
| US20070219951A1 (en) | Join predicate push-down optimizations | |
| US6643636B1 (en) | Optimizing a query using a non-covering join index | |
| US7702627B2 (en) | Efficient interaction among cost-based transformations | |
| US6122644A (en) | System for halloween protection in a database system | |
| US7991765B2 (en) | Cost-based query rewrite using materialized views | |
| CA2324741C (en) | Method for providing a system maintained materialized functionally dependent column for a database management system | |
| US6266663B1 (en) | User-defined search using index exploitation | |
| Baldacci et al. | A cost model for SPARK SQL | |
| US20100036804A1 (en) | Maintained and Reusable I/O Value Caches | |
| US6999967B1 (en) | Semantically reducing the number of partitions involved in a join | |
| US6253196B1 (en) | Generalized model for the exploitation of database indexes | |
| Graefe | Executing nested queries | |
| Morzy et al. | Materialized data mining views | |
| Feldman et al. | A knowledge-based approach for index selection in relational databases | |
| Schkolnick et al. | Considerations in developing a design tool for a relational DBMS |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |