Abstract: A database engine and optimizer framework support creation of a series of profiling indices over a column having character string data, such as a traditional “varchar” data type. The profiling indices result in a reduction of the number of records that are searched when searching for a sub-string match within that column. In some embodiments, the series of indices are created over a column that is typically searched using the LIKE predicate or some similar technique; these indices indicate for each record whether certain sub-strings may exist in that record's value in the column. Thus, the indices are used to find the rows that may match one or more portions of the particular term being queried or, in other words, eliminate those records that do not have at least a portion of the term to be matched. The number of records actually retrieved and searched for the query sub-string is thereby reduced.

Abstract: A database management system predicts a selectivity for database query conditions requiring a join of records from different tables. The system identifies at least one skewed value in a field specified in the join condition, and constructs, for each skewed value, a set of hypothetical query predicates in which the field specified in the join condition is replaced with a constant equal to the skewed value. The system then predicts the selectivity for the hypothetical predicates, using any appropriate prediction technique. The selectivities of the hypothetical predicates are used to predict a selectivity for the original query.

Abstract: A method, apparatus, system, and signal-bearing medium that, in an embodiment, receive a close command directed to a window, and determine whether the close command was received within a close threshold time of the display of the window. If the close command was received within the threshold time, in various embodiments, a close dialog is displayed, the window is faded, the window is shrunk, or a status message is displayed indicating that the window is closing. If a cancel command is received within a cancel-close threshold, the closing of the window is canceled. If the number of times the cancel command has been received for the window exceeds a cancel threshold, then in various embodiments, the close threshold is increased, magnification is recommended, a sound option is recommended, or speech recognition is recommended. In an embodiment, in response to a close command directed to a window, a determination is made whether the number of times the window has been resized is greater than a resize threshold.

Abstract: A database engine and optimizer framework support creation of a series of profiling indices over a column having character string data, such as a traditional “varchar” data type. The profiling indices result in a reduction of the number of records that are searched when searching for a sub-string match within that column. In some embodiments, the series of indices are created over a column that is typically searched using the LIKE predicate or some similar technique; these indices indicate for each record whether certain sub-strings may exist in that record's value in the column. Thus, the indices are used to find the rows that may match one or more portions of the particular term being queried or, in other words, eliminate those records that do not have at least a portion of the term to be matched. The number of records actually retrieved and searched for the query sub-string is thereby reduced.

Abstract: An improved method and apparatus is described for a query optimizer to evaluate multi-table join selectivities in a computer database. The query optimizer includes a statistics manager that finds the most appropriate set of assumptions and statistics to use when calculating the cost of an arbitrary join expression. As described herein, the statistics manager implements a unique bucket representation for the join expression. The bucket representation for the join expression can be evaluated and compared to the traditional domino expression so that the best possible estimate can be used. This new representation of the join expression allows the query optimizer to more accurately estimate the join selectivity for many queries compared to traditional representations.

Abstract: A query plan modification system and method relate to a database system that includes a cost-based optimizer for generating access plans. The database system also permits a user to view an access plan that has been generated by a particular SQL query and modify the access plan if desired. The user specifies customizations that are associated with the access plan so that when that plan is executed, the customizations are executed as well. Exemplary customizations include specifying an initialization file specific to a query, specifying different implementation methods than those in the original access plan, prohibiting rebuilding of an access plan, and over-riding or ignoring a clause within the query that is used to generate the access plan.

Abstract: A query plan modification system and method relate to a database system that includes a cost-based optimizer for generating access plans. The database system also permits a user to view an access plan that has been generated by a particular SQL query and modify the access plan if desired. The user specifies customizations that are associated with the access plan so that when that plan is executed, the customizations are executed as well. Exemplary customizations include specifying an initialization file specific to a query, specifying different implementation methods than those in the original access plan, prohibiting rebuilding of an access plan, and over-riding or ignoring a clause within the query that is used to generate the access plan.

Abstract: A query engine (or optimizer) which supports database queries having user-defined functions maintains historical execution data with respect to each of multiple user-defined functions. The historical execution data is dynamically updated based on query execution performance. When executing a query having user-defined functions, the query engine uses the historical execution data to predict an optimal evaluation ordering for the query conditions and, preferably, to dynamically adjust the evaluation order when appropriate. Preferably, the historical execution data includes historical execution time of the user-defined function and proportion of evaluated records which satisfied the query parameters.

Abstract: A query engine (or optimizer) which supports database queries having user-defined functions maintains historical execution data with respect to each of multiple user-defined functions. The historical execution data is dynamically updated based on query execution performance. When executing a query having user-defined functions, the query engine uses the historical execution data to predict an optimal evaluation ordering for the query conditions and, preferably, to dynamically adjust the evaluation order when appropriate. Preferably, the historical execution data includes historical execution time of the user-defined function and proportion of evaluated records which satisfied the query parameters.

Abstract: A query engine (or optimizer) which supports database queries having user-defined functions maintains historical execution data with respect to each of multiple user-defined functions. The historical execution data is dynamically updated based on query execution performance. When executing a query having user-defined functions, the query engine uses the historical execution data to predict an optimal evaluation ordering for the query conditions and, preferably, to dynamically adjust the evaluation order when appropriate. Preferably, the historical execution data includes historical execution time of the user-defined function and proportion of evaluated records which satisfied the query parameters.

Abstract: A query plan modification system and method relates to a database system that includes a cost-based optimizer for generating access plans. The database system also permits a user to view an access plan that has been generated by a particular SQL query and modify the access plan if desired. The user specifies customizations that are associated with the access plan so that when that plan is executed, the customizations are executed as well. Exemplary customizations include specifying an initialization file specific to a query, specifying different implementation methods than those in the original access plan, prohibiting rebuilding of an access plan, and over-riding or ignoring a clause within the query that is used to generate the access plan.

Abstract: An apparatus, program product and method that build column statistics utilizing at least one skew value. The column statistics built using skew values, instead of column statistics built only through random sampling, may be used to more accurately reflect skew values across join networks, and thus enable a query optimizer to better select an access plan that is optimal under current runtime conditions.

Abstract: An apparatus and program product that build column statistics utilizing at least one skew value. The column statistics built using skew values, instead of column statistics built only through random sampling, may be used to more accurately reflect skew values across join networks, and thus enable a query optimizer to better select an access plan that is optimal under current runtime conditions.

Abstract: A database query optimizer allows specifying a performance specification for a query. When an access plan is created, the actual performance for executing the query using the access plan is determined and compared to the performance specification for the query. If the actual performance does not satisfy the performance specification for the query, the query optimizer autonomically generates a different access plan to see if the performance improves. If an access plan that meets the performance specification is generated, the new access plan is stored in the access plan cache for the query. If no access plan can be generated that meets the performance specification for the query, the access plan that provided the best performance is selected and stored in the access plan cache for the query.

Abstract: A database query optimizer allows specifying a performance specification for a query. When an access plan is created, the actual performance for executing the query using the access plan is determined and compared to the performance specification for the query. If the actual performance does not satisfy the performance specification for the query, the query optimizer autonomically generates a different access plan to see if the performance improves. If an access plan that meets the performance specification is generated, the new access plan is stored in the access plan cache for the query. If no access plan can be generated that meets the performance specification for the query, the access plan that provided the best performance is selected and stored in the access plan cache for the query.

Abstract: Methods are provided for dynamically selecting indexes during the execution of a database query, to optimize performance. In one embodiment, a query is provided for joining a target table and a source table. Rows of the target table are selected that simultaneously satisfy at least first and second criteria. The first criterion specifies values of a first column of the target table as a function of values of a first column of the source table and the second criterion specifies values of a second column of the target table as a function of values of a second column of the source table. A plurality of indexes are generated, including at least a first index using the first column of the target table and a second index using the second column of the target table.

Abstract: An enhanced mechanism for intelligently managing an open query cursor built from a query access plan (AP) by a query optimizer of a database management system (DBMS). In an embodiment, a cursor management system (CMS) detects whether an open query cursor was previously requested for use within another job. If the open query cursor was previously requested, the CMS intelligently manages the query cursor for subsequent use within a different job. For example, the open query cursor may be recycled for subsequent use within the different job. Hence, system resources are not wasted in building and destroying the same cursors for multiple jobs. Alternatively, the query cursor may be pre-built before the cursor is requested for subsequent use within the different job. The CMS may also obtain, release and re-obtain locks for cursors being managed. Alternatively, the job that uses the cursor may obtain the lock.

Abstract: A database engine and a system running a database engine utilize a dynamic bitmap updating routine to avoid the delay associated with building an entire bitmap. When running a query on a table, the database engine can build a bitmap over a column of the table that helps avoid unnecessary I/O operations to retrieve records. The database engine initializes the bitmap so that all elements have a value of “1”, or active, and proceeds to scan and retrieve the records of the table according to the bitmap using a first process. Any retrieved record is further analyzed to determine if it is part of the result set. Concurrently, a second process is initiated which continually updates the values within the bitmap according to a set of selection criteria. As the first process continues to operate, more and more elements of the bitmap are set to “0”, or inactive, so that the first process can avoid unnecessary I/O operations.

Abstract: A method that builds column statistics utilizing at least one skew value. The column statistics built using skew values, instead of column statistics built only through random sampling, may be used to more accurately reflect skew values across join networks, and thus enable a query optimizer to better select an access plan that is optimal under current runtime conditions.

Abstract: A database engine and a system running a database engine utilize a dynamic bitmap updating routine to avoid the delay associated with building an entire bitmap. When running a query on a table, the database engine can build a bitmap over a column of the table that helps avoid unnecessary I/O operations to retrieve records. The database engine initializes the bitmap so that all elements have a value of “1”, or active, and proceeds to scan and retrieve the records of the table according to the bitmap using a first process. Any retrieved record is further analyzed to determine if it is part of the result set. Concurrently, a second process is initiated which continually updates the values within the bitmap according to a set of selection criteria. As the first process continues to operate, more and more elements of the bitmap are set to “0”, or inactive, so that the first process can avoid unnecessary I/O operations.