Compressed Join Plan Transformation for Faster Database Queries

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing database systems face limitations in processing speed due to hardware constraints, data storage methods, and restricted co-processing options, particularly when handling large volumes of data.

Innovation Solution

A database system architecture that employs parallelized data input, storage, retrieval, and query processing systems, utilizing a network of computing devices and nodes with independent processing core resources to distribute and optimize query execution, including techniques like Global Dictionary Compression and optimized join processes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If traditional database systems process large volumes of data, then data storage capacity is maintained, but processing speed deteriorates due to hardware constraints

Engineering Contradiction:
Improveprocessing speedVSAvoiddata volume
Core Design Contradiction:
ProductivityVSQuantity of substance

Solution Approach 1:

The patent segments the database system into multiple independent computing devices (nodes) that operate in parallel. Each node has its own processing core resources and can independently handle portions of data processing tasks. This segmentation allows the system to maintain processing speed when handling large volumes of data by distributing the workload across multiple segments rather than concentrating it in a single system.

Inventive Principle:
Principle #1Segmentation

2Productivity

If data is stored in traditional formats, then storage simplicity is maintained, but query execution speed deteriorates

Engineering Contradiction:
Improvequery execution speedVSAvoiddata storage method
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent transforms the data storage format by encoding data values as integers representing positions in sorted arrays rather than storing raw values. This parameter change in the storage format enables faster query execution through efficient integer comparisons and position-based lookups, while the systematic encoding method maintains reasonable storage complexity.

Inventive Principle:
Principle #35Parameter changes

3Productivity

If co-processing options are restricted, then system simplicity is maintained, but processing capability deteriorates

Engineering Contradiction:
Improveprocessing capabilityVSAvoidco-processing options
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The patent creates a universal processing architecture where computing devices can perform multiple functions including data processing, query execution, and result generation. Each node in the distributed system is multi-functional, capable of handling various types of operations independently, thereby enhancing overall processing capability without requiring specialized co-processing units for each function.

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

Data Source

PatentUS20260064777A1Additional global dictionary compression join plan transformation
Publication Date: 2026.03.05 OCIENT HOLDINGS LLC
  • US20260064777A1 patent drawing
  • US20260064777A1 patent drawing
  • US20260064777A1 patent drawing

AI summary

A query and response sub-system of a database system includes a set of processing core resources that is operable to receive a query regarding a dataset. The query includes a join operation regarding a set of tables, which includes compressed data, and a specific query operation that operates on data of the join table. The set of processing core resources are further operable to optimize the query in accordance with an optimization process to produce an optimized query. The optimization process includes determining whether the specific query operation is capable of operating on the compressed data. When the specific query operation is capable of operating on the compressed data, positioning the specific query operation before the join operation in the optimized query. When the specific query operation is not capable of operating on the compressed data, positioning the specific query operation after the join operation in the optimized query.