Sap Se

Sap Ag

Sung Heun Wi

Sang Kyun Cha

Ki Hong Kim

Chanho Jeong

Taehyung Lee

Sangyong Hwang

Yongsik Yoon

Sang Il Song

Juchang Lee

Jeong Ae Han

Norman May

Johannes Merx

Sang Yong Hwang

Christian Bensberg

Christoph Weyerhaeuser

Tobias Mindnich

Alexander Boehm

Chul Won Lee

Joo Young Yoon

Jane Jung Lee

Myunggon Park

Nosub Sung

Junhee Woo

Stefan A Baeuerle

Chang Gyoo Park

Kyu Hwan Kim

Andreas Kemmler

Jaeyun Noh

Kai Morich

Jin Uk Bae

Dan Bi Park

Jung Kook Lee

Christian Kraus

Florian Scheid

Chui Won Lee

Jiyoung Yoo

Christoph Glania

Armin Risch

Devices, methods and systems for processing database queries formatted differently than the database storage model being queried are disclosed. Processing database queries independent of the storage model of the queried database may be performed by receiving a query for one or more data items stored in a database, determining whether to use at least one query operator that uses data having a format different from the storage model format of at least one of one or more data items stored in the database and converting the format of the data used by the at least one query operator to a format that matches the storage model format of at least one of one or more data items stored in the database. Related systems, methods, and articles of manufacture are also described.

Processing database queries using format conversion

A process is provided for independently hashing and filtering a data set, such as during preprocessing. For the data set, one or more records, separately having one or more fields, may be identified. A record hash value set, containing one or more record hash values for the respective one or more records, may be generated. Generating a given record hash value may be accomplished as follows. For a given record, a hash value set may be generated, having one or more field hash values for the respective one or more fields of the given record. The record hash value for the given record may be generated based on the hash value set. A total hash value for the data set may be generated based on the record hash value set. The records of the data set may be filtered based on classification of the query that generated the records.

Order-independent multi-record hash generation and data filtering

Implementations of the present disclosure include receiving, by a query processing server, a first query, the first query including a syntax indicating that precision loss is allowed, processing, by the query processing server, the first query to provide a first QEP, optimization of which would result in precision loss in a generated query result, determining that the syntax is provided, and in response, optimizing the first QEP to provide an optimized QEP, executing the optimized QEP to generate a query result that includes data stored within a database system, the query result having reduced accuracy relative to a query result that would be generated based on the first QEP, and providing the query result as output from the database system.

Selectively allowing query optimization in query processing

Methods, systems, and computer-readable storage media for calculating, for each operator in a set of operators, a set of costs, each cost associated with a data format and including a first segment indicating a cost of an operator to convert an incoming data format to an access format and a second segment indicating a cost based on a set of costs of one or more ancestors of the operator, a conversion cost, and a materialization cost, indicating, along the path within the query plan, a location representing execution of a conversion from a first data format to a second data format, the location being selected based on the sets of costs, and providing the query plan with the location for execution to generate a query result, wherein during execution of the query plan, conversion of data from the first data format to the second data format occurs at the location.

Optimizing output data formats to improve query performance in database systems

Methods and apparatus, including computer program products, are provided for a case join. In one aspect, there is provided method, which may include receiving a query for a predefined view that is configured to inhibit modification; detecting whether the predefined view includes a database table extended to include an additional column; and generating, in response to the query, a view based on a case join, when the predefined view includes the database table extended to include the additional column. Related apparatus, systems, methods, and articles are also described.

Case join decompositions

Technologies for performing garbage collection in database systems, such as multi-version concurrency control (MVCC) database systems, are described. For example, different garbage collection techniques can be used separately or in various combinations, including interval garbage collection, group garbage collection, table garbage collection, and combinations. For example, a particular type of combination, called hybrid garbage collection, uses technique from interval garbage collection and group garbage collection, or from interval, group, and table garbage collection.

Group garbage collection for multi-version concurrency control in database systems

In one aspect there is a method. The method may include associating a query received from an application with a hint, wherein the hint modifies an execution of the query. The method may further include an optimizer to compile the query according to the hint to produce a second query plan. When no hint is associated with the query, the optimizer may produce a first query plan. The method may further include storing the hint in a persistent table to enable state preservation during a database restart or binary upgrade, and/or executing the query using the second query plan.

Query plan optimization by persisting a hint table

A method may include receiving a query for data to be provided by a database server, wherein the query includes an indication of a maximum lag. The method may further include determining whether a hint is available to apply to the query, wherein the hint affects an execution of the query. When no hint is available, a baseline database server may be selected to be the database server. When the hint is available, a replication server or a cache server may be selected to be the database server based on the hint and the maximum lag. The query may be processed at the selected database server.

Query hints for caching and replication

In a general aspect, a computer-implemented method for executing a query on a table of a database, where the table has multiple partitions, can include receiving a query requesting a view on the table. The view on the table can be based on data included in a partition of the multiple partitions of the table. The method can also include determining a cached result to the query is not available in the database and generating a result to the query from, at least, the data of the partition of the multiple partitions. After the generating, the method can include building a cache including the result to the query, associating a transaction identifier for the query with the result to the query result in the cache; and returning the result to the query.

Caching views on historical data

Disclosed herein are system, method, and computer program product embodiments for utilizing join cardinality to improve the performance of query processing. An embodiment operates by a database engine receiving a query including a join operation on a first and a second table using a join predicate, and a tag for the join operation indicating a cardinality relationship between the first and the second table when satisfying the join predicate. Then, the database engine generates a query processing plan for performing the query. For the join operation, the database engine selects one of the first or the second tables to remove from the join operation based on a type of the join operation and the tag. Based on the selecting, the database engine may remove may the join operation and the selected table from the query processing plan.

Query optimization using join cardinality

Embodiments relate to view caching techniques that cache for a limited time, some of the (intermediate) results of a previous query execution, in order to avoid expensive re-computation of query results. Particular embodiments may utilize a cache manager to determine whether information relevant to a subsequent user request can be satisfied by an existing cache instance or view, or whether creation of an additional cache instance is appropriate. At design time, cache defining columns of a view are defined, with user input parameters automatically being cache defining. Cache instances are created for each tuple of literals for the cache defining columns, and for each explicit or implicit group by clause. Certain embodiments may feature enhanced reuse between cache instances, in order to limit memory footprint. Over time a cache instances may be evicted from memory based upon implementation of a policy such as a Least Recently Used (LRU) strategy.

Cached views

Growing community of inventors

Gyeonggi-do, South Korea

Sung Heun Wi