Method for Estimating Cardinalities for Query Processing in a Relational Database Management System

This invention relates to database management systems and more particularly to a method for estimating key cardinalities for query processing in a relational database management system.

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 table has one or more columns.

The RDBMS 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 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 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 plan comprises a translation of the user's SQL commands in terms of the RDBMS operators. There may be several alternative query plans generated by the query optimizer, each specifying a set of operations to be executed by the RDBMS. The many query 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 plan in order to determine which plan has the lowest execution cost. In order to determine a query 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 plan however manipulated or rearranged.

In a SQL based RDBMS the query plan comprises a set of primitive operations or commands, e.g. JOIN; a sequence in which the retrieve operations will be executed, e.g. JOIN ORDER; a specific method for 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, knowledge of cardinalities, i.e. the number of rows to be processed at various stages in the query execution plan, is crucial to the generation and selection of an efficient query execution plan.

One important cardinality is the number of rows which results from a grouping operation or a duplicate removal operation. A grouping operation gathers together rows having the same value on specified columns, known as grouping columns, to produce a single row. The duplicate removal operation is a special case of grouping and involves keeping only one row for a group of identical rows.

Both the grouping and duplicate removal operations have the same characteristic, namely, the production of a resulting table in which no two rows share the same value for a set of columns. For the grouping operation, these columns are termed the grouping columns, and in the duplicate removal operation, the resulting columns are the retrieved columns. (In the SQL query language, the GROUP BY command provides a grouping operation and the DISTINCT command provides a duplicate removal operation.) The resulting columns are termed a "key". If the number of distinct values for certain columns or key can be accurately estimated, then the cardinality can be determined after the columns are grouped. The cardinality is known as the "key cardinality". Because the key cardinality value can affect the performance of queries, the accurate estimation of the key cardinality is critical to the query optimizer for selecting an efficient query plan.

In the prior art, the key cardinality is determined by multiplying the effective cardinality of each individual column in the key to obtain the overall cardinality for the key. The column cardinality represents the number of distinct values for a column. When there are one or more local predicates being applied to the column, the effective column cardinality is the cardinality of the column after the local predicates have been applied. The technique according to the prior art is based on the assumption that all columns in a key are fully independent of each other. Because this assumption does not hold in most cases, the estimated cardinality for the key is still typically a very large number which can cause the query optimizer to choose an unsuitable query plan.

The deficiencies of the prior art technique can be illustrated more thoroughly by an example. In SQL, a grouping request is generated by the "GROUP-BY" clause and duplicate row elimination is generated by the "DISTINCT" clause. The following sample SQL QUERY includes a grouping operation denoted by the GROUP BY clause. ##STR1##

In this example, the actual key cardinality of the grouping columns is 181. The estimated key cardinality determined according to the prior art is 5,832,000, which provides a very poor estimate for the actual value of 181. Because the choice of query plan depends on the accurate estimation of the key cardinality, the estimation of the key cardinality is critical to the performance of a query.

What is needed in the art is a method for accurately estimating key cardinalities.

The present invention provides a method for estimating cardinalities for query processing in a relational database management system. The present method is suitable for use with a query optimizer for estimating cardinalities for sets of columns or keys resulting from a grouping operation or a duplicate removal operation.

It is an object of the present invention to provide a method for estimating cardinalities that accounts for the effect of local predicates on non-key columns.

It is another object of the present invention to provide a method for estimating cardinalities which determines column equivalence classes and uses the minimum effective column cardinality for the class to estimate the key cardinalities.

It is another object of the present invention to provide a method for estimating effective index key cardinality which accounts for the effect of local predicates on columns in the table.

It is another object of the present invention to produce a better cardinality estimate by utilizing information and attributes which can be obtained from the catalog for the relational database management system. The additional information includes cardinalities for existing unique keys, column equivalence classes, functional dependencies, statistical functional dependencies, and statistically unique keys.

In a first aspect, the present invention provides a method for estimating cardinalities for a key formed from a grouping of columns in a table for use in a query optimizer for a relational database management system, wherein selectivities and keys associated with columns in the table are provided in a catalog, said method comprising the steps of: (a) determining an equivalence class for each column in said key; (b) for each said equivalence class determining an effective cardinality for each of said columns belonging to said equivalence class; (c) determining a cardinality for each of said equivalence classes by choosing the minimum effective cardinality for the columns belonging to said equivalence class; and (d) estimating a cardinality value for said key from the product of said cardinalities for said equivalence classes.

In another aspect, the present invention provides a method for estimating the cardinalities for a key formed from a grouping of columns in a table for use in a query optimizer for a relational database management system, wherein selectivities and index keys are provided in a catalog, said method comprising the steps of: (a) forming one or more partitions from the columns in said grouping, said partition having a plurality of subsets with each said subset comprising a column or a selected index key from the catalog; (b) determining an index key cardinality for each of said subsets; (c) obtaining a cardinality for said partition from the product of the index key cardinalities for each subset belonging to said partition; and (d) obtaining a cardinality value for the grouping of columns by choosing the minimum cardinality from the cardinalities determined for each of said partitions.

In yet another aspect, the present invention provides a method for estimating cardinalities for a key formed from a grouping of columns belonging to a table for use in query optimizer for a relational database management system, wherein selectivities and functional dependencies associated with columns belonging to the table are provided in a catalog, said method comprising the steps of: (a) obtaining functional dependencies for the columns belonging to said grouping; (b) deleting a column which is functionally determined by another column in said grouping; (c) repeating step (b) until all functionally determined columns have been deleted; (d) determining an effective column cardinality for each remaining column; and (e) estimating a cardinality for said grouping of columns from the product of said effective cardinalities.

In another aspect, the present invention provides a method for estimating cardinalities for a key formed from a grouping of columns in a table for use in a query optimizer for a relational database management system, wherein selectivities and keys associated with columns are provided in a catalog, said method comprising the steps of: forming a set of keys comprising said key and other keys selected from said catalog; and obtaining a cardinality for said key by choosing the minimum cardinality value for said keys comprising said set.

In yet a further aspect, the present invention provides a method or estimating cardinalities for a key formed from a grouping of columns in a table for use in a query optimizer for a relational database management system, wherein selectivities and keys, including unique and index keys, associated with columns in the table are provided in a catalog, said method comprising the steps of: (a) forming a set of keys comprising said key and unique keys selected from said catalog; (b) determining an equivalence class for each column belonging to said set; (c) for each said equivalence class determining an effective column cardinality for said columns belonging to said equivalence class; (d) determining an equivalence class cardinality for each of said equivalence classes by choosing the minimum effective column cardinality for the columns belonging to said equivalence class; (e) forming a combination of columns by choosing a column from each of said equivalence classes; (f) dividing said combination into one or more partitions, each said partition having a plurality of subsets with each said subset comprising a column or a selected index key from said catalog; (g) determining an effective index key cardinality for each of said subsets; (h) obtaining a cardinality for said partition from the product of said effective index key cardinalities for each subset belonging to said partition; (i) determining a cardinality for said combination by choosing the minimum cardinality for said partitions; (j) repeating said steps (e) to (i) for other combinations; (k) obtaining a cardinality value for the key selected in said step (a) by choosing the minimum cardinality of said combinations; (l) repeating said steps (a) to (d) for other keys selected from said catalog; and (k) obtaining a cardinality for said key by choosing the minimum cardinality value determined of all said selected keys.

Reference will now be made, by way of example, to the accompanying drawings, which show a preferred embodiment of the present invention, and in which:

FIG. 1 is a block diagram showing software components of a relational database management system suitable for a method for estimating cardinalities according to the present invention; and

FIG. 2 is a block diagram showing a data processing system employing the present invention.

Reference is made to FIG. 1 which shows in block diagram form a Relational Database Management System or RDBMS system 10 suitable for use with a method according to the present invention. One skilled in the art will be familiar with how a RDBMS is implemented. Such techniques are straightforward and well known in the art. Briefly, the RDBMS 10 comprises a client application module 12 and a server module 14 as shown in FIG. 1. One of the functions of the server 14 is to process the SQL query entered by the database user. The server 14 comprises a relational data services and SQL compiler 16. The SQL compiler 16 includes a plan optimization module 18 or query optimizer.

The primary function of the query optimizer 18 is to find an access strategy or query plan that would incur or result in minimum processing time and input/output time for retrieving the information requested by the user. In FIG. 1, the query plan is represented by block 20.

Reference is next made to FIG. 2 which shows a data processing system 22 incorporating the present invention. The data processing system 22 comprises a central processing unit 24, a video display 26, a keyboard 28, random access memory 30 and one or more disk storage devices 32. One skilled in the art will recognize the data processing system 22 a conventional general purpose digital computer. In FIG. 2, the relational database management system 10 incorporating the present method comprises a software module which is stored or loaded on the disk storage device 32. Data items, e.g. cards, tables, rows, etc. which are associated with the relational database management system 10 can be stored on the same disk 32 or on another disk 34.

In database query processing, the knowledge of resulting cardinalities, i.e. qualifying number of rows associated with the query, is important to the generation of efficient query plans. One important cardinality is the number of rows resulting from a user query which utilizes a grouping operation or a duplicate row removal operation. In the SQL language, the GROUP BY and DISTINCT operations provide grouping. Both operations have the same characteristics, namely, the resulting table will comprise a set of columns in which no two rows share the same value. This set of columns is called a key. If the number of distinct values for the key can be accurately estimated, a key cardinality for the set is obtained. The key cardinality is important to the generation of an efficient query plan, and thus can directly affect the performance of the RDBMS, especially in the case of complex queries.

The present invention provides a method for estimating key cardinalities which can be incorporated into the query optimizer represented by block 18 in FIG. 1. The query optimizer utilizes the key cardinality determined according to the method in selecting an efficient query plan. It will be understood that the present invention is suitable for other database management systems such as the known INFORMIX.TM. and SYBASE.TM. systems and not limited to the architecture depicted in FIG. 1.

In the following description, the terms column cardinality and effective column cardinality are used as follows. Column cardinality is the number of distinct values, i.e. rows, for a column. Effective column cardinality is the cardinality of a column after one or more local predicates have been applied to the column. Since duplicate removal (i.e. DISTINCT operation in SQL) is a special case of the grouping operation (i.e. GROUP BY in SQL), the grouping operation in this description will refer to either one of these operations.

The present invention provides a method for estimating the cardinalities for a set of columns or key. The set of columns corresponds to the result produced by a grouping operation or duplicate removal operation in a query. The present method accounts for the effects of local predicates on the set of columns and also the effects of local predicates on other columns in the table but not belonging to the set. The method for estimating cardinalities of column groupings also utilizes selected index key cardinalities which are available in the CATALOG. According to the present method, the effects of local predicates on the index key cardinalities are also taken into account. In order to generate improved and more accurate estimates of key cardinalities, the present method also includes a number of additional operations which utilize other attributes associated with the columns in the table. These attributes include the following:

(1) cardinalities of existing unique keys,

(2) column equivalence classes,

(3) functional dependencies,

(4) statistically unique keys,

(5) statistical functional dependencies

The sequence and number of processing steps performed will depend on the type and attributes or characteristics of the columns being queried as will be described in more detail below.

The operation of the method for estimating cardinalities according to the present invention is described with reference to the following pseudocode listing.

The first step in Line 1 of the present method involves inputting the key K comprising columns C in the resulting table T. The columns C comprising the key K are the result of a grouping operation or duplicate removal operation, for example, the "GROUP BY" clause or "DISTINCT" clause in the SQL query language. The present method will produce an estimate for the cardinality of the key K, i.e. key cardinality, for the columns C in the resulting table. The estimated key cardinality is used by the query optimizer 18 (FIG. 1) to generate a query execution plan as will be understood by one skilled in the art.

In Line 2 of the present method, the functional dependencies and the statistical functional dependencies are obtained. A functional dependency is defined as follows: column A functionally determines column B, if for any two rows the columns agree on the value for A, then they also agree on the value for B. Similarly, a set of columns A functionally determines another set of columns B if for any two rows in the table they agree on the values for A and they also agree on the values for B. It follows that the number of distinct values for B is bounded by the number of distinct values for A. Therefore according to the present method, if columns B (or a subset of B) are a grouping key, then the cardinality of B is bounded by the cardinality of columns A. The use of functional dependencies according to the present invention is further shown by the following example.

For the above example, the prior art method would estimate the key cardinality as 1000, i.e. .vertline.C2.vertline.=1000 which is considerably larger than the value according to the present method.

One skilled in the art will be familiar with how to obtain the functional dependencies from the optimizer module and therefore additional pseudocode for this operation in Line 2 is not provided.

Statistical functional dependencies are also obtained in Line 2 and are used by the present method to estimate key cardinalities. A column is a statistically unique key if the cardinality of the column is very close, i.e. 95%, to the cardinality of the table. This also means that the column statistically functionally determines all the columns of the table. The utilization of statistical functional dependencies by the present method is shown using the following example SQL QUERY.

The prior art method estimates the cardinality for above example as .vertline.C1.vertline.*.vertline.C2.vertline.*ff.sub.-- 3=100*1950*1%=1950 which is a clearly inaccurate estimate.

The statistical functional dependencies can be determined in Line 2 from information contained in the CATALOG for the relational database management system and accessing the CATALOG will be apparent to one skilled in the art.

In Line 3, the present method determines the unique keys and statistically unique keys associated with the table T and forms a set S in Line 4. The set S comprises the unique keys, the statistically unique keys and the key K.

The unique keys can be determined from the CATALOG as will be within the understanding of one skilled in this art. According to the invention, a unique key is formed from a set of columns in a table where no two rows contain the same value for these columns. As will be described, the present method determines the minimum cardinality of all the unique keys in the table and uses this as the cardinality for the grouping key. This follows because if the table cardinality is bounded by any unique key cardinality, then the cardinality of any grouping key should also be bounded by the unique key cardinality. The following example QUERY further describes this operation.

In the above example, the method according to the prior art would estimate the cardinality to be 10*20*3000=600000. This represents a very poor estimate when compared to the estimated value of 200 generated according the present method.

The statistically unique keys are also derived from information which is in the CATALOG. According to the present method, a statistically unique key comprises a column (or set of columns) which has a cardinality that is very close, i.e. 95%, to the cardinality of the table. (If the cardinality of a column is identical to the cardinality of the table T, then the column is a unique key.) The utilization of a statistically unique key according to the present invention can be further described by the following example SQL QUERY.

The method for estimating cardinalities according to the prior art would have produced an estimate of 1000. Once again the prior art method provides an inaccurate estimate which can cause the query optimizer 18 (FIG. 1) to pick a wrong or inefficient query plan.

Database systems typically contain many tables which include undeclared unique keys, for example, the TPCD database has the CNAME column in the CUSTOMERS table which is an undeclared unique key. The method according to the invention exploits this and other information to generate an accurate estimate of the key cardinality. Although approximate uniqueness can be estimated throughout the query optimization process, it is preferable to derive the statistically unique keys based on base table catalog statistics. The determination of statistically unique keys will be apparent to one skilled in the art and therefore pseudocode for this operation in Line 3 is not provided.

Starting at Line 5, the present method involves performing a number of operations for each key k in set S. In Lines 6 to 9, the method involves finding and deleting any columns C which are functionally determined by other columns in set K. This operation is repeated until all the functionally determined columns have been deleted. After the operation in Lines 6 to 9, set S comprises the keys, i.e. unique keys, statistically unique keys and key K, with the functionally determined columns deleted. The method uses set S to estimate the key cardinality for the table T. The remaining steps as will now be described involve using the "keys" in set S and other information to produce an accurate estimate for the cardinality of key K.

For each key k in set S, the column equivalence class is determined in Line 11. If two columns functionally determine each other, then they belong to the same column equivalence class. The column equivalence class represents a grouping of columns which are equivalent. Assuming columns C1 and C2 belong to the same column equivalence class, then according to the present method, the cardinality of C1 is bounded by the cardinality of C2, and the cardinality of C2 is bounded by the cardinality of C1. Furthermore, the cardinality of either columns is bounded by the minimum effective cardinalities of C1 and C2. In a RDBMS, equivalence columns are typically generated by join predicates, e.g. the predicate (C1 join C2) would result in columns C1 and C2 belonging to the same column equivalence class.

The utilization of column equivalence classes by the method according to the present invention is further described by the example QUERY which follows.

The method according to the prior art would estimate the cardinality for the above example as 10,000 which provides an inaccurate estimate.

Once the column equivalence classes have been obtained for each column in key k, the effective minimum cardinality for each column in the column equivalence class is determined as indicated in Lines 12 to 13.

To determine the effective cardinality of a column in Line 13, the method according to the present invention considers the effect of local predicates on other columns in the equivalence class. Known query optimizers estimate the cardinality of a column C1 using only the product of predicate selectivity (ff.sub.-- 1) and base table column cardinality .vertline.C1.vertline. obtained from the CATALOG. Known optimizers do not consider the effects of predicates on other columns. According to the invention, the effective cardinality of a column is determined by the following expression which will be referred to as Expression (1):

where:

.vertline.T.vertline. is the table cardinality, i.e. number of rows in table

.vertline.C1.vertline. is the base table cardinality obtained from the CATALOG

ff.sub.-- 1 is the selectivity of a local predicate for column C1

ff.sub.-- 2 is the selectively of a local predicate for column C2

In the derivation of Expression (1) according to the present method, it is assumed that C1 and C2 are independent, and the values of C1 and C2 are both uniformly distributed in the table.

If there is no restriction on column C2, i.e. ff.sub.-- 2 is 1, Expression (1) reduces to .vertline.C1.vertline.*ff.sub.-- 1 which provides the basic operation performed by known optimizers for obtaining the effective cardinality of a column. Since the prior art method is based on the assumption that all columns in a key are fully independent of each other, the method according to the prior art usually leads to unnecessarily large numbers for the key cardinalities. This in turn can result in the query optimizer 18 (FIG. 1) picking the wrong query plan which is clearly undesirable.

The operation (and improved results) of Expression (1) according to the present invention for estimating the effective cardinality can be described by way of the following example QUERY:

For the above example, the method according to the prior art would estimate the effective cardinality of the column to be 18000 (i.e. .vertline.C1.vertline.*ff.sub.-- 1=20000*90%). It can be seen that the method according to the invention provides a much better estimate when compared to the prior art approach.

To determine the effective cardinality of a set of columns (denoted by C), the Expression (1) is generalized as follows and denoted as Expression (2) :

where:

.vertline.C.vertline. is the product of base table column cardinalities for the group

.vertline.T.vertline. is the table cardinality

ff.sub.-- C is the selectivity for C, which is the product of selectivities of all columns in C

ff.sub.notC is the selectivity for all columns in the table not belonging to C Expression (2) reduces to .vertline.C.vertline.'=.vertline.C.vertline.*ff.sub.-- C if there are no local predicates on columns outside of C, i.e. ff.sub.notC is 1.

Once the effective cardinality for each column in the equivalence class has been determined (i.e. using Expression (1)), then, in Line 14, the minimum effective cardinality of all column cardinalities is taken as the cardinality for the column equivalence class. As described above, the cardinality of the columns comprising an equivalence class is bounded by the minimum effective cardinality of all column cardinalities.

In Line 15, the present method forms a combination k' by choosing a column from each column equivalence class (as determined above). In Line 16, the combination k' is then divided into one or more partitions based on index key cardinalities. A partition comprises a set of non-intersecting subsets of k and the union of these subsets produces k. A subset can comprise a column or one of the index key cardinalities. The subsets are used to determine the cardinality of the partition as will be described below.

The index key cardinality is another key which is utilized by the present method. As described above, partitions are formed in Line 16 on the basis of index key cardinalities as part of the process for estimating key cardinalities according to the invention. Indexing is a facility provided by the RDBMS for providing access to a table. An index is defined as a set of index entries for a particular table. An index entry corresponds to one row in the table and each entry comprises two parts: an index key and a tuple identifier. The index key comprises a sequence of columns in the row which are associated with the index. The tuple identifier identifies the position in the DASD, e.g. disk, that contains the row.

In most database systems various types of statistics are collected for an index and these can be accessed in the CATALOG for the database. The index key cardinality is one such statistic utilized by the present method. Because the sequence or ordering of index key columns is significant, only cardinality counts for sets of columns that form a prefix for an entire index key are available in the CATALOG. For example, the number of unique values in the first column of the index is the first key cardinality, the number of unique values in the first two columns of the index is the second key cardinality and so on until the entire index key corresponds to the full key cardinality.

The method according to the present invention uses index key information when a query references the same columns as in the index key. The utilization of the index key according to the present method is described in more detail with reference to the following example SQL QUERY.

For the above example, the prior art method would estimate the cardinality as 72000000 (i.e. 20*30*40*50*60). The present method produces a much more accurate estimate of 100 by determining if a pre-existing index key cardinality can be used and then deriving the estimate from the index key cardinality.

Referring back to Line 16 of the pseudocode listing, a subset for partition corresponds to an index key or column and comprises either a column, the first two key cardinality, the first three key cardinality, the first four key cardinality or the full key cardinality. It will be understood that the definition of a subset will depend on the index keys which can be determined. Once all the subsets (and partitions) have been determined, the next operation, in Lines 17 to 18, involves finding the effective key cardinality for each subset in the partition.

The effective index key cardinality determined according to the present method considers the effect of local predicates on the index key cardinality. According to the invention, the effective index key cardinality is obtained using the following expression:

where:

K is the first "n" key of an index, where n can be 1 to the number of columns in the index

.vertline.K.vertline. is the first "n" key cardinality obtained from the catalog

.vertline.T.vertline. is the table cardinality

ff.sub.-- K is the product of selectivities of local predicates on columns in K.

ff.sub.notK is the product of selectivities of local predicates on columns in the table not belonging to K

In the above expression, the "n" index key cardinality can be taken as the cardinality for K because the product of column cardinalities will be no less than the "n" index key cardinality and the latter value is the more accurate one. The operation of Expression (3) according to the present invention can be illustrated by the following example SQL QUERY:

The approach taken by the prior art method would simply estimate the cardinality as (C1*ff.sub.-- 1)*(C2*ff.sub.-- 2)=100*80%*200*90% to produce a value of 14400. The prior art method fails to consider the effects of predicates on the non-key column C3 nor does it utilize the index key cardinality. As can be seen, the resulting cardinality of 14400 is a very poor estimate.

Once the effective cardinalities for each subset have been determined in Line 18, the cardinality for the partition is obtained by multiplying, in Line 19, the cardinalities for each of the subsets. Because the subsets are independent, the cardinality for a partition is determined by the product of the cardinalities for the subsets.

In Line 20, the cardinality for the combination k' is determined by selecting the minimum cardinality for all partitions belonging to the combination k'. This follows because the cardinality of combination k' is bounded by the cardinality of the partition. Similarly, in Line 21, the cardinality for the key k is determined from the minimum cardinality for all the combinations k' and in Line 22 minimum cardinality of the all the keys k is the estimated cardinality for the key K, i.e. grouping of columns produced by GROUP BY or DISTINCT operation in SQL for example.

It will be understood that the techniques embodied in the present method as described above can be employed in any sequence and that according to the invention any subset of the techniques can also be applied.

The operation of the present method will now be described with respect to the SQL sample query which was shown above.

For the first sub-group in the GROUP BY clause, i.e. (T3.C4, T3.C5, T3.C6), the full index cardinality is known to be 6, and the product of the individual column cardinalities is 6*5*6 which gives 180. The present method compares the full index cardinality to the product of individual column cardinalities and determines the cardinality for this sub-group to be 6. For the second sub-group in the GROUP BY operation, i.e. (T4.C3, T4.C4), the index cardinality is estimated as 25 from the full index cardinality and the product of the individual column cardinalities is 2*3. From this information, the method according to the present invention estimates the cardinality for the second sub-group as 6. For the third sub-group comprising the columns (T2.C2,T2.C3,T2.C4,T2.C5,T2.C6), the cardinality for the sub-group is estimated from the full index cardinality as 6 and from the product of the individual column cardinalities as 5400 (5*6*6*5*6). According to the present method, the cardinality for the sub-group is determined as 6. The cardinality for the grouping is determined from the product of cardinalities for each sub-group as determined above, i,e. 6*6*6. Following the above steps, the method according to the present invention estimates the key cardinality to be 216. The actual key cardinality is 181, while the cardinality estimated according to the prior art would be 5,832,000. It can be seen that the method according to the invention provides a significant improvement over the prior art.

The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The embodiments of the present invention described above are to be considered in all respects only as illustrative and not restrictive in scope. The scope of the invention is, therefore, indicated by the appended claims rather than by the detailed description above. Therefore, all changes which come within the meaning and range of equivalency of the claims are to be considered embraced within their scope.