Fine-Grained Physical Operators for Heterogeneous SQL Execution

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing relational database systems face inefficiencies in processing high-volume data due to the use of coarse-grained relational operators that are not optimized for modern hardware and data structures, leading to suboptimal data processing and inefficient query execution.

Innovation Solution

Decompose relational operators into finer-grained physical operators that are hardware-independent and can handle columnar data, allowing for dynamic optimization based on fluctuating conditions and heterogeneous hardware, using a directed acyclic graph (DAG) to facilitate more efficient dataflow and offloading to diverse hardware platforms.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If a relational operator tree approach is used to process queries, then query execution can be supported with standard relational algebra operations, but data processing efficiency deteriorates for high volume data due to coarse-grained operations and row-by-row processing

Engineering Contradiction:
Improvedata processing efficiencyVSAvoidrelational operator tree complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent divides the coarse-grained relational operators into finer-grained physical operators that can be independently optimized and executed. This segmentation allows each operator to be tailored for specific hardware architectures and data formats, improving processing efficiency while reducing the complexity of individual operator implementations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a new dimension by mapping relational operators to physical operators that operate on columnar data structures rather than row-based data. This dimensional change enables vectorized processing and better hardware utilization, transforming the execution model from row-by-row to columnar batch processing.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

2Productivity

If columnar data storage is used to support vectorized processing, then processing throughput can be improved, but query execution efficiency deteriorates when relational operators eagerly decode and transform columns back to row-major data

Engineering Contradiction:
Improveprocessing throughputVSAvoiddata transformation time
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The patent extracts the data transformation step from the relational operator execution. By introducing dedicated physical operators that can consume columnar data directly, the system eliminates the need for relational operators to eagerly decode and transform data, thereby reducing time loss while maintaining throughput benefits.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces physical operators as intermediaries between columnar data storage and query execution. These physical operators act as mediators that can efficiently consume columnar data without requiring full decoding and transformation, enabling optimized data flow through the query execution plan.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If relational operators are designed to handle all possible use cases with static plan optimization, then query plan generality is improved, but runtime performance deteriorates due to inability to adapt to specific data distributions and hardware conditions

Engineering Contradiction:
Improvequery plan adaptabilityVSAvoidruntime query performance
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent introduces dynamic adaptability by allowing the query execution plan to be adjusted at runtime based on actual data distributions and hardware conditions. Physical operators can be dynamically selected and optimized based on fluctuating workloads, enabling the system to adapt to specific use cases while maintaining high runtime performance.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent enables parameter changes in the execution plan by allowing dynamic selection of physical operators based on data types, data distributions, and hardware capabilities. This flexibility allows the system to optimize parameters such as batch sizes, data formats, and operator implementations based on actual runtime conditions.

Inventive Principle:
Principle #35Parameter changes

4Ease of manufacture

If a legacy row processing model is used, then compatibility with existing database systems is maintained, but hardware optimization potential is lost on modern architectures

Engineering Contradiction:
Improvesystem compatibilityVSAvoidhardware utilization efficiency
Core Design Contradiction:
Ease of manufactureVSProductivity

Solution Approach 1:

The patent achieves universality by designing physical operators that can operate on both columnar and row-major data formats. This multi-functionality allows the system to maintain compatibility with existing row-based database operations while simultaneously leveraging modern columnar storage and vectorized processing capabilities for improved hardware utilization.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentEP4328761B1Techniques of heterogeneous hardware execution for SQL analytic queries for high volume data processing
Publication Date: 2025.09.17 ORACLE INT CORP
  • EP4328761B1 patent drawingFigure 3
  • EP4328761B1 patent drawingFigure 5
  • EP4328761B1 patent drawingFigure 5

AI summary

In an embodiment, a method comprises: receiving (402) a data access request (110) to read and/or write data in a plurality of relational tuples, wherein the data access request (110) does not designate a pivot column; compiling (404) the data access request (110) into a query plan, wherein the query plan includes at least one particular operator that is selected from the group consisting of a transpose operator and a rotate operator; executing (406) the query plan, wherein executing (406) the query plan comprises transforming, by the particular operator, the plurality of relational tuples; generating (408) a response (150) to the data access request (110) that is based on said transforming, by the particular operator, the plurality of relational tuples. One or more non-transitory computer-readable storage media comprise corresponding features.