Abstract: An index advice record engine generates and stores index advice records. An index advice policy mechanism allows a user to define an index advice policy that specifies criteria for autonomic index creation, modification and deletion. An autonomic index mechanism reads the index advice records, compares this information with the criteria in the user-defined index advice policies, and determines whether an index should be created, modified or deleted based on the information in the index advice records and the index advice policies. By automating the process of creating, modifying and deleting indexes according to user-defined policies, the preferred embodiments alleviate human users from most of the work of manually creating, modifying and deleting indexes.

Abstract: An index advice record engine generates and stores index advice records. An index advice policy mechanism allows a user to define an index advice policy that specifies criteria for autonomic index creation. An autonomic index creation mechanism reads the index advice records, compares this information with the criteria in the user-defined index advice policies, and determines whether an index should be created based on the information in the index advice records and the index advice policies. By automating the process of creating indexes according to user-defined policies, the preferred embodiments alleviate human users from most of the work of manually creating indexes.

Abstract: An apparatus, program product and method utilize a query optimizer that identifies Join types in a query plan that can be replaced to facilitate optimization of the plan. If the query plan is considered to have a tree-graph representation, then the optimizer locates Join nodes to be replaced and substitutes an Inner Join node and additional nodes that do not inhibit optimization strategies and algorithms. As a result, all Outer Joins, whether left or right, and all Exception Joins, whether left or right, can be removed from the query plan before performing optimizations such as predicate movement, GROUP BY movement, ORDER BY movement, and Join enumeration.

Abstract: Optimizers must work with numeric data from a variety of sources including column statistics, estimated filter factors, record counts estimated costs and the like. Embodiments provided herein define and represent any such numeric measurements as a Vector of N dimensions, where n is a number of aspects of measurements that a particular optimizer is configured to consider. A particular embodiment provides a 4-dimensional vector where the dimensions represent magnitude, confidence, variance interval, and penalty. Examples of measurements considered by the optimizer, and which may be represented as a vector, include cost, estimated selectivity of a predicate, estimated number of records returned from part or all of a query, estimated record fanout when joining one file to another, etc.

Abstract: A database query optimizer constructs a graph comprising nodes, relations, and expressions. The query optimizer then constructs execution plans for sub-parts of the graph. The combination of execution plans make up the overall execution plan for the query. The execution plan information is appended to the graph itself, allowing changing an execution plan in one portion of the graph without necessarily changing execution plans in other portions of the graph. By representing a query using the graph of the preferred embodiments that includes execution plan information, the query optimizer is able to evaluate the execution plans of different options quickly and efficiently, thereby enhancing the performance of the query optimizer.

Abstract: An apparatus, program product and method utilize a query optimizer that relies upon a plurality of dynamically-dispatchable active strategy entities to generate an optimized execution plan for a database query. The plurality of active strategy entities form a optimizer framework from which the knowledge available to the optimizer, and the intelligence utilized by the optimizer in generating execution plans, may be represented in a structured, flexible, extensible and easily-modifiable manner.

Abstract: An apparatus, program product and method utilize a query optimizer that relies upon a plurality of dynamically-dispatchable active strategy entities to generate an optimized execution plan for a database query. The plurality of active strategy entities form a optimizer framework from which the knowledge available to the optimizer, and the intelligence utilized by the optimizer in generating execution plans, may be represented in a structured, flexible, extensible and easily-modifiable manner.

Abstract: A database query optimizer constructs a graph comprising nodes, relations, and expressions. The query optimizer then constructs execution plans for sub-parts of the graph. The combination of execution plans make up the overall execution plan for the query. The execution plan information is appended to the graph itself, allowing changing an execution plan in one portion of the graph without necessarily changing execution plans in other portions of the graph. By representing a query using the graph of the preferred embodiments that includes execution plan information, the query optimizer is able to evaluate the execution plans of different options quickly and efficiently, thereby enhancing the performance of the query optimizer.

Abstract: Query results and statistics regarding them are generated using a novel representation of an n-attribute relation as an order n relational tensor. Orders of the relational tensor respectively correspond to each of the attributes, and each coordinate along an order relates to a key value of the corresponding attribute. Numeric values are stored in the relational tensor, each numeric value representing a count of tuples having the attribute key values that correspond to the coordinate of the numeric value along the orders of the relational tensor. This storage representation is useful in a variety of contexts for enhancing the performance of a RDBMS system. Specifically, a data-representing relational tensor can be used to produce results for join operations such as the SQL operations JOIN, LEFT OUTER JOIN, RIGHT OUTER JOIN and FULL OUTER JOIN.

Abstract: Optimizers must work with numeric data from a variety of sources including column statistics, estimated filter factors, record counts estimated costs and the like. Embodiments provided herein define and represent any such numeric measurements as a Vector of N dimensions, where n is a number of aspects of measurements that a particular optimizer is configured to consider. A particular embodiment provides a 4-dimensional vector where the dimensions represent magnitude, confidence, variance interval, and penalty. Examples of measurements considered by the optimizer, and which may be represented as a vector, include cost, estimated selectivity of a predicate, estimated number of records returned from part or all of a query, estimated record fanout when joining one file to another, etc.

Abstract: Query results and statistics regarding them are generated using a novel representation of an n-attribute relation as an order n relational tensor. Orders of the relational tensor respectively correspond to each of the attributes, and each coordinate along an order relates to a key value of the corresponding attribute. Numeric values are stored in the relational tensor, each numeric value representing a count of tuples having the attribute key values that correspond to the coordinate of the numeric value along the orders of the relational tensor. This storage representation is useful in a variety of contexts for enhancing the performance of a RDBMS system. Specifically, in a first aspect of the invention, a tensor representation can be used to generate statistics for a user query so that the relational database system can determine, from among two candidate approaches, an approach to use in processing the user query based on the statistic.

Abstract: A method and computer program product are provided for implementing skip key processing for database grouping queries involving aggregate operations using one or more indices in a computer system. First checking for a selected entry in a current group in a primary file is performed. Responsive to finding the selected entry in the current group, the set of records of the current group is ordered to provide an aggregate value in an aggregate field of the current group. Then checking for an excluded value in the aggregate field of the current group is performed. Responsive to not finding the excluded value in the aggregate field, a current entry is saved as a result for the group. Then checking for more groups in the primary file is performed. Responsive to finding more groups in the primary file, a unique key or prefix to the query index is obtained to position to a next group. When the selected entry in the next group is not found, then checking for more groups in the primary file is performed.

Abstract: A method and computer program product are provided for processing and combining data sets including bitmaps in a computer system. A plurality of initial data subsets to be combined are processed and data structure statistics containing predefined data attributes are built for each of the plurality of initial subsets. Checking for a dynamic selection attribute for each of the plurality of initial subsets is performed. Responsive to the dynamic selection attribute not being identified, the intermediate storage requirements for producing the combined final data set is selectively optimized. Responsive to identifying the dynamic selection attribute, both intermediate result regeneration and intermediate storage requirements for producing a combined final data set are selectively optimized.

Abstract: A method and computer program product are provided for processing subquery join composites using hash join in a computer system. A hash table is built for a first table to be joined with a second table. A cursor is built for the second table. For each tuple in the second table, the hash table for the first table is probed. If a match is found, then any non-equal join predicate is evaluated. A unique fanout join is processed to return an error if a tuple or row from the second table joins to more than one row in the first table where the result of the basic predicate subquery can only be one row. A distinct fanout join is processed when the tuple or row from the second table joins to a row in the first table, the row is returned, advancing to a next tuple in the second table without checking for any more matches on the first table.