Producer-Driven Execution Plan for Database Query Optimization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The Volcano-based iterator model in current database systems leads to poor CPU resource usage and increased instruction misses due to long execution paths and numerous function calls, resulting in inefficient query execution performance, especially in in-memory database servers.
Innovation Solution
A simplified native access plan (SNAP) is generated by converting the query execution plan into optimized native machine code using a producer-driven model, leveraging LLVM IR and Just-in-Time compilation to reduce branch statements and improve instruction and data locality.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the Volcano-based iterator model is used for query execution, then the execution plan can be built from basic operators with open-next-close protocol, but the CPU resource usage increases and instruction misses occur due to long execution paths and numerous function calls
Solution Approach 1:
The patent replaces the mechanical iterator-based execution model with a producer-driven execution model that uses direct function calls and optimized code paths. Instead of using generic iterator protocols with multiple function calls (open, next, close), the system generates specialized producer functions that directly produce tuples through optimized code paths, eliminating the overhead of the mechanical iterator interface while maintaining query execution flexibility
Solution Approach 2:
The patent changes the execution model parameters from consumer-driven iterator protocol to producer-driven direct execution. By transforming the execution plan into a producer-driven model with optimized code generation, the system alters how operators execute - instead of responding to next() calls, producers actively push tuples through optimized paths, changing the fundamental execution parameters to improve CPU utilization and reduce instruction misses
2Ease of manufacture
If the iterator-based execution model with open-next-close protocol is used, then operators can be self-contained and modular, but the code paths become long and CPU efficiency decreases
Solution Approach 1:
The patent merges the modular operator concepts with producer-driven execution by generating integrated producer functions that combine multiple operator operations into single optimized code paths. Instead of separate open/next/close function calls for each operator, the system merges these operations into unified producer functions that maintain modularity benefits while eliminating the CPU overhead of multiple function call boundaries
Solution Approach 2:
The patent extracts the essential functionality from the iterator protocol and implements it directly in producer functions. By taking out the core tuple production logic from the generic iterator framework and implementing it as specialized producer code, the system removes the unnecessary overhead of the iterator interface while preserving operator modularity through targeted code generation
3Adaptability or versatility
If numerous function calls are used in the execution plan, then operator functionality can be separated and reused, but instruction misses increase and execution speed decreases
Solution Approach 1:
The patent applies preliminary action by pre-generating optimized producer code that embeds operator functionality directly into the execution path. Instead of calling functions dynamically during execution, the system performs code generation beforehand to create optimized producer functions that have direct access to operator logic, eliminating runtime function call overhead while preserving operator reusability through the code generation framework
Data Source
AI summary
An original query execution plan of a database query is received. The original query execution plan represents a tree of operators. Source code for the original query execution plan is generated by a single traversal of the tree of operators. The generated source code is compiled into native machine code. The native machine code represents a simplified native access plan (SNAP).