|Publication number||US6879977 B2|
|Application number||US 09/757,428|
|Publication date||Apr 12, 2005|
|Filing date||Jan 10, 2001|
|Priority date||Apr 28, 2000|
|Also published as||CA2307155A1, US8825616, US20010037329, US20050004906, US20080256053|
|Publication number||09757428, 757428, US 6879977 B2, US 6879977B2, US-B2-6879977, US6879977 B2, US6879977B2|
|Inventors||Paul C. Huffman, Kathy A. McKnight, David C. SHARPE, Daniel C. ZILIO|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (31), Referenced by (10), Classifications (17), Legal Events (5)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention is directed to an improvement in computing systems and in particular to improved database query execution where the query being executed includes filtering operations.
In query processing systems, such as the relational database management system (RDBMS) DB2™, data values are extracted from stored images of the data for further processing by the query evaluation system. Typically, the data is structured as rows comprised of column values, said rows being grouped into contiguous storage blocks known as pages. A part of the task of query evaluation comprises the process of isolating successive rows and extracting a (possibly proper) subset of the columns of the row for subsequent query evaluation steps such as filtering, sorting, grouping, or joining.
Extracting column values from pages involves steps of identifying and locating in main memory the page containing the next needed row, locating the next needed row within the page, locating the needed column values within the needed row, and copying the needed column values to new locations in memory where they are made available for subsequent query evaluation steps. Typically, locating a page in memory requires determining whether the page is in main memory and, if so, determining where in memory the page is located. If the page is not in main memory, the page must be brought to main memory from secondary storage (typically from disk).
Additionally, in query evaluation systems supporting concurrent query executions, steps must be taken to stabilize the page to ensure that it remains at the same location in memory and to avoid concurrent read and updates to the page to preserve the logical integrity of the page contents. Subsequent to copying needed column data values to new locations, the page stabilization conditions must be released.
The steps of accessing data by locating a page, stabilizing the page, locating a row in the page, and releasing stabilization for each row to be processed by the query evaluation system can constitute a significant portion of the overall execution cost of a query.
Prior art query evaluation systems, such as RDBMSs, use different approaches to avoid repeatedly accessing rows in a page by following the potentially costly steps set out above. For example, where there are predicates in queries that are to be satisfied, it is possible to evaluate the predicates for located rows before retrieving the sets of column values of interest for the queries. Where a row does not meet the predicate condition, the next row (potentially on the same page in the data) may be accessed without requiring a renewed stabilization of the page. The existing location in the page is also known, which may reduce the cost of locating the next row.
This application of predicates to column values of a current row while the column values still lie with their row in the currently identified page is sometimes called search argument (or SARG) processing. This processing approach allows the system to continue to the next row on the same page without releasing page stabilization, re-identifying the location of the page in memory, and re-stabilizing the page whenever the SARG predicate(s) are not satisfied. Additionally, programmatic book keeping associated with transfer of control between page processing and query evaluation components of the query processing system can be avoided for rows which would soon be discarded subsequent to a predicate being evaluated using the copied column values.
Another prior art approach to reducing the need to restabilize the data page involves processing the needed columns of the current row directly from its page in the data and continuing directly to the next row on the page. Typical processing operations which can “consume” column values directly from the page include sorting (enter column values into the sorting data structure) or aggregation (include column values in the running results for SUM, AVG, MAX, etc.). This type of processing is sometimes referred to as “consuming pushdown”, because there is a ‘pushdown’ of a consuming operation into data access processing.
The above approaches, however, apply only where there is a predicate to be evaluated, or where there is a consuming operation carried out as part of the query execution. In query processing systems, such as RDBMSs, there are other types of queries that are potentially costly to execute and which are therefore not susceptible to the above approach. An example of such a query is a query having non-predicate and non-consuming operations but which filter data values.
It is therefore desirable to have a query processor which is able to execute a query including filtering in a manner that reduces the number of page stabilizations required to execute the query.
According to one aspect of the present invention, there is provided an improved execution of database queries including filtering operations. According to another aspect of the present invention, there is provided a method for processing a database query resulting in an access plan, including a filtering criteria, in a database management system comprising a data manager, a set of data, a query manager, the method comprising the steps of:
According to another aspect of the present invention, there is provided the above method in which the set of data is stored on pages and the method further comprising the step of the data manager stabilizing the page on which the query-specified data is located prior to access said data, the method further comprising the step of maintaining the stabilization of the page during callback to the query manager.
According to another aspect of the present invention, there is provided the above method in which the database query comprises an SQL DISTINCT clause.
According to another aspect of the present invention, there is provided a program storage device readable by a machine, tangibly embodying a program of instructions executable by the machine to perform method steps for processing queries for a database, said method steps comprising the method steps of claim 1, 2 or 3.
According to another aspect of the present invention, there is provided a computer program product for a database management system comprising a data manager, a set of data, and a query manager for processing a database query resulting in an access plan, including a filtering criteria, the computer program product comprising a computer usable medium having computer readable code means embodied in said medium, comprising:
According to another aspect of the present invention, there is provided the above computer program product, in which the set of data is stored on pages and in which the computer usable medium having computer readable code means embodied in said medium, further comprises:
According to another aspect of the present invention, there is provided a query processing system comprising a data manager, a set of data, and a query manager for processing a database query resulting in an access plan, including a filtering criteria,
According to another aspect of the present invention, there is provided the above query processing system, in which the set of data is stored on pages and data manager further comprises means for stabilizing the page on which the query-specified data is located prior to access said data, and means for maintaining the stabilization of the page during callback to the query manager.
According to another aspect of the present invention, there is provided a query processing system comprising a data manager for accessing data records located in pages in a set of stored data, the data manager stabilizing a page on which a data record is stored before accessing the record, the query processing system also comprising:
According to another aspect of the present invention, there is provided the above query processing system, in which the data manager applies the designated filtering operator to the next located record by calling the query processor to carry out the filtering operation.
Advantages of the present invention include improved efficiency for the execution of database queries that include filtering operations.
The preferred embodiment of the invention is shown in the drawing, wherein:
In the drawing, the preferred embodiment of the invention is illustrated by way of example. It is to be expressly understood that the description and drawing are only for the purpose of illustration and as an aid to understanding, and are not intended as a definition of the limits of the invention.
In query processing systems that support concurrent access to data, the location and stabilization of a page containing data is a potentially expensive operation. Each time that data management system 16 stabilizes a page in data 18, and locates (using a notional cursor, in the preferred embodiment) a position in the page in data 18, there will be a resulting time cost added to the processing of the query.
Where a query includes a filtering operation, such as that carried out by the DISTINCT operator found in SQL, there may be significant calls from data management system 16 to data 18 to retrieve rows for filtering by query processor 14. As explained above, repeated accessing of data 18 where pages are stabilized and then released on each access, incorporates potentially avoidable inefficiencies in the query processing.
In the system of the preferred embodiment, non-predicate filter processing may be carried out without the data management system 16 releasing the stabilization of the page in data 18 which is being read from. It is therefore possible to carry out non-predicate filtering directly on column values of a current row while the column values are “in place” in the stabilized and located row in the currently identified page.
The approach of the preferred embodiment is described with reference to the following Program Description Language (PDL) of processing a query including the keyword DISTINCT. The example is presented as showing execution first without, and then with, the execution steps of the preferred embodiment. The example uses the following query on table “employee” have column “name”:
SELECT DISTINCT name FROM employee;
In the following PDL fragments, query_processor corresponds to query processor 14, and data_manager corresponds to data management system 16 as shown for the RDBMS of FIG. 1. In the RDBMS query execution without the steps of the preferred embodiment, the access plan for the above query results in the following execution:
In the above approach, the DISTINCT filtering operation is done after the page is released and each row is produced by data_manager to query_processor.
The query processing of the example query using the approach of the preferred embodiment results in the following access plan being implemented:
The above description for the simple SQL query including filtering (by the DISTINCT keyword) illustrates the improvement of the preferred embodiment. The data manager is able to keep the data page stabilized over multiple rows where the filtering specified by the DISTINCT keyword results in rows being skipped in the processing of the query.
The preferred embodiment provides better query processing performance in comparison with processing that requires repeated calls to data manager 16, in FIG. 1. This is because, in a manner similar to SARG and consuming pushdown (referred to above), filtering the record allows the system to continue to the next row on the same page without releasing page stabilization, re-identifying the location of the page in memory, and re-stabilizing the page whenever the filtering operations are not satisfied. Additionally, programmatic bookkeeping associated with transfer of control between page processing and query evaluation components of the query processing system can be avoided for rows which would soon be discarded subsequent to a predicate being evaluated using the copied column values.
A further basis for increased query processing performance with the preferred embodiment system is related to the current state of the art in the architecture of central processing units (CPUs) on which the preferred embodiment will be implemented. In such CPUs, resource utilization is increased by spatial and temporal locality of reference. When a CPU references data and/or instructions that are near to other data or instructions, both in time and space, then the CPU is able achieve improved performance. A fast (but relatively small) cache is found near or on the CPU in many current CPUs. This cache is intended to be filled when new data or instruction locations are referenced. Subsequent references to the same data or instructions, or to proximate data or instructions that were loaded in the cache as part of the caching method, are retrieved from the (fast) cache. Where the CPU carries out access in this manner using the cache, the CPU is able to process data and instructions more quickly than where there is access to instructions or data not resident in the cache.
The preferred embodiment system permits a looping process to be carried out over the rows contained in a page. This looping process improves utilization of CPUs by increasing the spatial and temporal locality of both instruction and data references and, thus, makes more effective use of instructions and data lodged in the processor memory caches.
The processing of queries using the preferred embodiment system can occur in conjunction with other pushdown approaches to query evaluation such as SARG, consuming and other filtering pushdowns. The filtering pushdown of the preferred embodiment does not preclude the data in a row located by data manager 16 and identified as being one of the rows successfully passing the defined filter also being subject to other predicate evaluation or consuming operations before being potentially returned to query processor 14.
It will also be apparent from this description that the filtering that is subject to the system of the preferred embodiment may be carried out where an SQL query (query 10 in
The rewritten query is the example set out above. The query is logically equivalent but will be able to make use of the approach of the preferred embodiment if rewritten including an express filtering operator (DISTINCT, in this case).
Although a preferred embodiment of the present invention has been described here in detail, it will be appreciated by those skilled in the art, that variations may be made thereto. Such variations may be made without departing from the spirit of the invention or the scope of the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5504873 *||Nov 12, 1993||Apr 2, 1996||E-Systems, Inc.||Mass data storage and retrieval system|
|US5506984 *||Jun 30, 1993||Apr 9, 1996||Digital Equipment Corporation||Method and system for data retrieval in a distributed system using linked location references on a plurality of nodes|
|US5598559 *||May 28, 1996||Jan 28, 1997||Hewlett-Packard Company||Method and apparatus for optimizing queries having group-by operators|
|US5706457 *||Jun 7, 1995||Jan 6, 1998||Hughes Electronics||Image display and archiving system and method|
|US5724570||Jun 7, 1995||Mar 3, 1998||Tandem Computers Incorporated||Method and apparatus for a complete SQL subquery elimination process|
|US5758149 *||Mar 17, 1995||May 26, 1998||Unisys Corporation||System for optimally processing a transaction and a query to the same database concurrently|
|US5758356 *||Sep 12, 1995||May 26, 1998||Hitachi, Ltd.||High concurrency and recoverable B-tree index management method and system|
|US5768578||Feb 27, 1995||Jun 16, 1998||Lucent Technologies Inc.||User interface for information retrieval system|
|US5899986 *||Feb 10, 1997||May 4, 1999||Oracle Corporation||Methods for collecting query workload based statistics on column groups identified by RDBMS optimizer|
|US5937401 *||Nov 27, 1996||Aug 10, 1999||Sybase, Inc.||Database system with improved methods for filtering duplicates from a tuple stream|
|US5950188 *||Nov 19, 1996||Sep 7, 1999||Sybase, Inc.||Database system with methods for executing system-created internal SQL command statements|
|US5987463 *||Jun 23, 1997||Nov 16, 1999||Oracle Corporation||Apparatus and method for calling external routines in a database system|
|US6026404 *||Oct 31, 1997||Feb 15, 2000||Oracle Corporation||Method and system for executing and operation in a distributed environment|
|US6049800 *||Oct 31, 1997||Apr 11, 2000||Oracle Corporation||Mechanism and method for performing callbacks|
|US6101531||Apr 15, 1998||Aug 8, 2000||Motorola, Inc.||System for communicating user-selected criteria filter prepared at wireless client to communication server for filtering data transferred from host to said wireless client|
|US6192370 *||Jun 19, 1998||Feb 20, 2001||Sap Aktiengesellschaft||Method and system for rapid memory-resident processing of transactional data|
|US6195653 *||Jan 13, 2000||Feb 27, 2001||International Business Machines Corporation||System and method for selectively preparing customized reports of query explain data|
|US6223171 *||Aug 25, 1998||Apr 24, 2001||Microsoft Corporation||What-if index analysis utility for database systems|
|US6249792 *||Dec 16, 1998||Jun 19, 2001||Microsoft Corporation||On-line dynamic file shrink facility|
|US6360228 *||Jun 2, 1999||Mar 19, 2002||Oracle Corporation||Transactional framework for executing statements involving non-native code|
|US6363387 *||Jul 31, 1999||Mar 26, 2002||Sybase, Inc.||Database system providing methodology for enhancing concurrency using row update bit and deferred locking|
|US6411951 *||Dec 16, 1998||Jun 25, 2002||Microsoft Corporation||Evaluating SQL subqueries|
|US6470330 *||Nov 2, 1999||Oct 22, 2002||Sybase, Inc.||Database system with methods for estimation and usage of index page cluster ratio (IPCR) and data page cluster ratio (DPCR)|
|JP2000067084A||Title not available|
|JP2000076288A||Title not available|
|JPH1040146A||Title not available|
|JPH1125096A||Title not available|
|JPH03108036A||Title not available|
|JPH09231115A||Title not available|
|JPH11328185A||Title not available|
|WO1997004407A1||Jul 13, 1996||Feb 6, 1997||Alcatel Nv||Emulator for an sql relational-database|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7725462||Dec 28, 2006||May 25, 2010||Teradata Us, Inc.||Applying segment conditions to measure results|
|US7984043||Jul 24, 2007||Jul 19, 2011||Amazon Technologies, Inc.||System and method for distributed query processing using configuration-independent query plans|
|US9195853||Jan 15, 2012||Nov 24, 2015||International Business Machines Corporation||Automated document redaction|
|US9224007||Sep 15, 2009||Dec 29, 2015||International Business Machines Corporation||Search engine with privacy protection|
|US20040220896 *||Apr 30, 2003||Nov 4, 2004||International Business Machines Corporation||System and method for optimizing queries on views defined by conditional expressions having mutually exclusive conditions|
|US20060095406 *||Oct 29, 2004||May 4, 2006||International Business Machines Corporation||Displaying explain data for a SQL query of a database|
|US20080162401 *||Dec 28, 2006||Jul 3, 2008||Scott Shelton||Applying segment conditions to measure results|
|US20110055932 *||Aug 26, 2009||Mar 3, 2011||International Business Machines Corporation||Data Access Control with Flexible Data Disclosure|
|US20110066606 *||Sep 15, 2009||Mar 17, 2011||International Business Machines Corporation||Search engine with privacy protection|
|US20110162084 *||Dec 29, 2009||Jun 30, 2011||Joshua Fox||Selecting portions of computer-accessible documents for post-selection processing|
|U.S. Classification||1/1, 707/999.003, 707/999.102, 707/999.104, 707/999.005, 707/999.002|
|International Classification||G06F17/30, G06F12/00|
|Cooperative Classification||Y10S707/99933, G06F17/30486, Y10S707/99945, Y10S707/99943, Y10S707/99935, G06F17/30492, Y10S707/99932|
|European Classification||G06F17/30S4P4P1D, G06F17/30S4P4P1|
|Jan 10, 2001||AS||Assignment|
|Sep 23, 2008||FPAY||Fee payment|
Year of fee payment: 4
|Nov 26, 2012||REMI||Maintenance fee reminder mailed|
|Jan 28, 2013||FPAY||Fee payment|
Year of fee payment: 8
|Jan 28, 2013||SULP||Surcharge for late payment|
Year of fee payment: 7