Sybase, Inc.

Google Inc.

Sap Se

Xun Cheng

Xiaobin Ma

Anjan Kumar Amirishetty

Viral Shah

Prabhas Kumar Samanta

Mihnea Andrei

Peter J Schneider

Anisoara Nica

Reza Sherkat

Nitesh Maheshwari

Xiao Ming Zhou

Christian Bensberg

Paul Willems

Alexander Boehm

Heping Shang

Zhen Tian

Yanhong Wang

Adrian Dragusanu

Edwin Anthony Seputis

Stephen Shepherd

Elton P Wildermuth

Haiyan Du

Mihnea Andre

Yuncong Qiao

Faming Qu

Hongyong Lu

Yanxin Luo

Haoyu Huang

Aspects of the disclosure are directed to early filtering of candidate rows for a join operator of a query statement before the join operator is evaluated to generate a result set. Early filtering, e.g., before execution of the join operator, reduces the number of candidate rows fetched from a database during a join operator, which can improve the rate at which queries including join operators are executed by a DBMS for the database. One or more Bloom filters or other probabilistic data structures can be produced and consumed according to different join conditions, allowing for early pruning of unqualified rows during a database scan operation.

Database join operations with early filtering

A hybrid query execution plan is generated for executing queries on database systems implementing a columnar cache. A hybrid query execution plan combines a query execution plan for querying and retrieving data from a columnar cache and a base table. A columnar cache stores cached data in column-major format, which is logically represented by the database management system in row-major format. A database management system as described herein can scan valid blocks of column data according to a column scan operation. The system can identify invalidated blocks and execute a different sub-execution plan of the hybrid query execution plan to scan corresponding rows in tables corresponding to the location of data for the invalidated blocks.

Columnar cache query using hybrid query execution plan

Aspects of the disclosure are directed to late materialization of attributes in response to queries to a database implementing a database cache. Queried data is materialized in temporary memory before the data is projected as part of generating a result to the query. Instead of materializing all of the attributes referenced in a query before executing the query, a database management system materializes attributes as 'late' as possible—when the operation needing the attributes is executed. The operation needing the attributes can be performed sooner, as opposed to materializing all referenced attributes are materialized before executing the query.

Late materialization of queried data in database cache

A method for providing elastic columnar cache includes receiving cache configuration information indicating a maximum size and an incremental size for a cache associated with a user. The cache is configured to store a portion of a table in a row-major format. The method includes caching, in a column-major format, a subset of the plurality of columns of the table in the cache and receiving a plurality of data requests requesting access to the table and associated with a corresponding access pattern requiring access to one or more of the columns. While executing one or more workloads, the method includes, for each column of the table, determining an access frequency indicating a number of times the corresponding column is accessed over a predetermined time period and dynamically adjusting the subset of columns based on the access patterns, the maximum size, and the incremental size.

Elastic columnar cache for cloud databases

Aspects of the disclosure provide for natively executing row-store expression data structures on column-store databases without rewriting. A database management system (DBMS) configured as described herein can maintain a mapping of row-store results to addresses of where corresponding column data is stored. When executing operators, such as logical operators, comparison operators, and/or function operators of a received query expression, the DBMS can operate on the column data, rather than the individual rows. The DBMS can store the results generated by executing the column operators, for example on a stack, and record the row-store addresses to which the stored results correspond. The DBMS responds with a number of rows corresponding to the processed column data.

Evaluating row-store expressions on a column-store database

Aspects of the disclosure are directed to generating a hybrid query execution plan for executing queries on database systems implementing a columnar cache. A hybrid query execution plan combines a query execution plan for querying and retrieving data from a columnar cache and a base table. A columnar cache stores cached data in column-major format, which is logically represented by the database management system in row-major format. A database management system as described herein can scan valid blocks of column data according to a column scan operation. The system can identify invalidated blocks and execute a different sub-execution plan of the hybrid query execution plan to scan corresponding rows in tables corresponding to the location of data for the invalidated blocks.

Disclosed herein are system, method, and computer program product embodiments for performing dynamic partition pruning using data statistic objects as data integrity constraints. An embodiment operates by partitioning a database table into a plurality of partitions based on a partition criterion. The embodiment creates a data statistics object for a partition in the plurality of partitions. The embodiment receives a query for the database table. The embodiment determines the data statistics object is consistent with data in the partition. The embodiment processes the query for the partition based on the data statistics object.

Constraint data statistics for dynamic partition pruning

Disclosed herein are system, method, and computer program product embodiments for determining a constraint data statistics object is consistent. An embodiment operates by receiving a query for a database table. The embodiment determines a constraint data statistic object associated with a partition of the database table. The embodiment determines the constraint data statistics object is consistent with a data state of the partition of the database table based on consistency metadata of the constraint data statistics object. The embodiment processes the query for the database table based on the determining the constraint data statistics object is consistent with the data state of the partition of the database table.

Synopsis based advanced partition elimination

A method, a system, and a computer program product for generating a query executable plan. A query requiring access to data stored in a database system is received. Based on the received query, a query execution plan having a plurality of query execution pipelines is generated. Each query execution pipeline in the plurality of query execution pipelines is configured to execute a plurality of operations in a predetermined order associated with each query execution pipeline. The generated query execution plan is fragmented into a plurality of fragments. Each fragment has one or more query execution pipelines in the plurality of query execution pipelines. The received query is executed by executing each fragment in the plurality of fragments.

Scaled-out query execution engine

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).

Generating a producer-driven execution plan from a consumer-driven iterator-based execution plan

A system and method for processing a database query is described. In response to detection that a database query involves a star or snowflake join operation, a join operator in a preliminary query plan can be split into a build operator and a probe operator. The probe operator can be placed in a final query plan in the same place as the join operator in the preliminary query plan, while the build operator can be placed beneath the probe operator in the final query plan, between an exchange operator and the exchange operator's child from the preliminary query plan.

Splitting of a join operation to allow parallelization

Disclosed herein are system, method, and computer program product embodiments for generating a native access plan for semi join operators. An embodiment operates by generating a plurality of variables based upon the positions of a plurality of operators in a compiled query plan, opening and traversing tables as the query plan is executed, and closing those tables based on the rows queried and the plurality of variables.

Generating a native access plan for semi join operators

Disclosed herein are system, method, and computer program product embodiments for generating a native access plan from a query execution plan for dynamic entity calling. An embodiment operates by receiving the query execution plan comprising at least one call to an entity, the entity being implemented by a plurality of classes, and generating source code of a native access plan that implements the query execution plan. The source code of the native access plan includes instructions to translate a run-time call to the entity to a call to a corresponding implementation of the entity based on an identifier of the called implementation of the entity.

Generating a native access plan for dynamic entity calling

Disclosed herein are system, method, and computer program product embodiments for eliminating redundancy when generating intermediate representation code. An embodiment operates by traversing a query execution plan, and for at least one operator in the query execution plan, determining whether the operator is derived from a parent class operator. If it is determined that the operator is derived from the parent class operator, source code for the native access plan is generated using one or more code generator functions corresponding to the parent class operator and/or one or more generator functions specifically corresponding to the child class operator. If it is determined that the operator is not derived from the parent class operator, source code for the native access plan is generated using one or more code generator functions corresponding to the operator.

Growing community of inventors

Dublin, CA, United States of America

Xun Cheng