Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-12-17
2001-06-19
Black, Thomas (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C707S793000, C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06249783
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates in general to computer-implemented database systems, and, in particular, to architecting the flow of built-in functions to enhance performance during runtime in a database system.
2. Description of the Related Art
Databases are computerized information storage and retrieval systems. A Relational Database Management System (RDBMS) is a database management system (DBMS) which uses relational techniques for storing and retrieving data. Relational databases are organized into tables which consist of rows and columns of data. The rows are formally called tuples. A database will typically have many tables and each table will typically have multiple tuples and multiple columns. The tables are typically stored on direct access storage devices (DASD), such as magnetic or optical disk drives for semi-permanent storage.
Processing information, e.g. user applied queries, in database systems through the execution of various functions used to be much simpler. In the past, only a few simple functions existed. Thus, all of the functions could be contained within a single module, a single logical location, for execution.
Over time, a larger number of database functions have been implemented and the functions have become more complex. In addition, databases have been taking on a greater burden by implicitly casting and converting between different data type formats. As a result, the number of functions and the cumulative size and complexity of these new functions have overflowed the simple module design. Thus, it is desirable to split the functions amongst multiple modules. This is so because, if at run time a function must be selected from a single large list of possible functions, i.e. in a single module, it becomes unwieldy to traverse the entire list each time a function must be executed. Thus, having a single module is not practical. However, a multiple module structure also has drawbacks, as module calls are resource expensive.
Each time a module is called, a great number of instructions must be executed to set up a new stack area, new data area, etc. Due to the large number of functions, there are a large number of modules, even if functions are broken up into units based on related types or classes. However, in order to be efficient at run time, there is a need to limit the number of module calls. The key is to properly define the units of work, the modules, which include not only the functions themselves, but also related operations, e.g. checking for nullity of data, encoding/decoding the function, etc.
While past systems have defined modules to handle a specific class type, there has been no optimization directed to holding module scope as long as possible. By holding module scope as long as possible, two goals are accomplished. First, there is a reduction in the number of expensive module calls. Second, the scope, or number, of functions examined within each module is reduced, which reduces processing effort.
Therefore, there is a need in the art for techniques that more efficiently execute built-in functions by holding module scope as long as possible.
SUMMARY OF THE INVENTION
To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a method, apparatus and article of manufacture for a computer-implemented method of efficiently executing built-in functions.
In accordance with the present invention, function modules are defined to process a single data type class. This allows the module to be optimized to the particular data type class and, thus, limits the number of functions to be recognized by a single function module. The modules are further defined to process as many functions as possible before returning to the caller. Users are likely to execute several functions on the same data type in a row. Therefore, the odds of being able to stay in the module and process the next function are good. Then, when a query to be applied to the database system is issued, functions related to the query are each assigned a key, a type of code, to indicate the data type class to which the function belongs. The functions to be executed are then ordered so that a particular module scope can be held as long as possible. Further, data fields, another type of code containing optimization information, can be added to the functions to further enable the holding of module scope. Finally, the functions are executed at runtime. During execution, the database system looks ahead at upcoming functions in an attempt to anticipate the next course of action by examining the keys and data fields which have been assigned to the functions. Various additional optimization techniques can then be used to enhance runtime performance.
An object of the present invention is to architect the flow of built-in functions to enhance performance during runtime. Recognizing functions and making module calls are expensive operations in terms of runtime performance. The provision of an efficient architecture can reduce the scale of these operations.
Another object of the present invention is to reduce the number of module calls made by holding the module scope as long as possible. This is accomplished through various optimizations of the flow of the functions.
Another object of the present invention is to reduce the cost of recognizing functions by eliminating functions not referenced in the current scope. This is accomplished by the definition of the modules to handle a particular data type class. The number of functions to be recognized by a particular module is limited, as the number of functions that operate on a particular data type is always less than the total number of functions.
REFERENCES:
patent: 5339430 (1994-08-01), Lundin et al.
patent: 5339438 (1994-08-01), Conner et al.
patent: 5410705 (1995-04-01), Jones et al.
patent: 5421016 (1995-05-01), Conner et al.
patent: 5428792 (1995-06-01), Conner et al.
patent: 5488727 (1996-01-01), Agrawal et al.
patent: 5493680 (1996-02-01), Danforth
patent: 5696974 (1997-12-01), Agrawal et al.
patent: 5754862 (1998-05-01), Jones et al.
patent: 5765147 (1998-06-01), Mattos et al.
patent: 5822750 (1998-10-01), Jou et al.
patent: 5875334 (1999-02-01), Chow et al.
patent: 5893104 (1999-04-01), Srinivasan et al.
Jim Melton (Sybase, Inc.) “An SQL3 Snapshot”, Data Engineering, 1996, , pp. 666-672, Mar. 1996.*
IBM Technical Disclosure Bulletin, vol. 40, No. 9, Sep., 1997, “Code Optimization by Hints to the Compiler”, pp. 125-128.
M. Clarke, et al. “An Architecture for Dynamically Extensible Operating Systems” Proceedings of the Fourth International Conference on Configurable Distributed Systems, (Cat. No. 98EX159), pp. 145-155, published: Los Alamitos, CA, 1998, viii+233 pp.
D. Lenkov, et al. “Type Identification in C++” Proceedings of the USENIX C++Conference Proceedings, pp. 103-118, published: Berkeley, CA, 1991, 243 pp.
Crone Christopher J.
Malone Patrick M.
Ruggles Jeffrey R.
Black Thomas
International Business Machines - Corporation
Mizrahi Diane D.
Sughrue Mion Zinn Macpeak & Seas, PLLC
LandOfFree
Method and apparatus for efficiently executing built-in... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for efficiently executing built-in..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for efficiently executing built-in... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2482843