Specialized Interpreter for Database Statement Execution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing database management systems face performance penalties due to the need for real-time parsing and interpretation of SQL statements, which incurs overhead and reduces system throughput, as they lack efficient mechanisms for generating machine code for database statements.
Innovation Solution
The solution involves specializing interpreter code within the database server to create machine code for database statements, using techniques like Partial Evaluation and Program/Algorithm Specialization, allowing for the generation of optimized machine code that reduces interpretive overhead and improves execution speed.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If SQL statements are interpreted by the database server at runtime, then the system can process any new SQL statement dynamically, but the execution speed is reduced due to interpretive overhead
Solution Approach 1:
The patent applies preliminary action by generating and caching execution plans for SQL statements before they are executed. The system parses SQL statements, generates execution plans, and stores them in a cache, so that when the same SQL statement is encountered again, the pre-generated execution plan can be reused immediately without re-parsing, thus improving execution speed while maintaining the ability to handle new statements dynamically
Solution Approach 2:
The patent uses copying by creating copies of execution plans for frequently executed SQL statements and storing them in a cache. Instead of interpreting the same SQL statement multiple times, the system creates and stores execution plan copies that can be rapidly retrieved and executed, reducing interpretive overhead while maintaining adaptability to new statements
2Speed
If a compiler generates machine code ahead of time, then execution speed is improved, but the system cannot process SQL statements that are not known until runtime
Solution Approach 1:
The patent applies dynamics by creating a hybrid system that combines interpretation and compilation. The system starts with interpretation to handle any SQL statement dynamically, then dynamically compiles frequently executed statements into machine code execution plans and caches them. This dynamic adaptation allows the system to maintain versatility for new statements while achieving compiler-level speed for recurring statements
Solution Approach 2:
The patent uses an intermediary approach by introducing an execution plan as an intermediate representation between the SQL statement and the actual execution. The execution plan serves as a mediator that can be generated through interpretation, optimized, cached, and executed as pre-compiled machine code, thus bridging the gap between interpretive flexibility and compiled speed
3Adaptability or versatility
If SQL statements are parsed and execution plans are created at database runtime, then flexibility in processing is maintained, but system throughput is reduced
Solution Approach 1:
The patent applies preliminary action by pre-generating and caching execution plans for SQL statements during idle periods or upon first execution. This allows the database server to process multiple identical or similar SQL statements using pre-prepared execution plans, significantly increasing system throughput while maintaining the flexibility to handle new statements by generating their execution plans on demand
Data Source
AI summary
After receipt of an instruction (e.g. a database statement), one or more computers specialize an interpreter with the received instruction as constant, to obtain a specialized interpreter that is stored in memory and/or disk. The specialized interpreter is then invoked to execute the received instruction. Depending on the embodiment, the interpreter being specialized may additionally be received and used in binary form without specialization. Specifically, in some embodiments, an identical interpreter is received in two forms: in a binary language specific to the one or more computers and also in a language that is acceptable to a specializer, such as a source language or an intermediate language. The interpreter in the binary language is invoked by default unless a predetermined condition for specialization is met. When the predetermined condition is met, the interpreter in the specializer-acceptable language is specialized by the specializer, and then the specialized interpreter is invoked.