Oracle International Corporation

Lucent Technologies Inc.

Ncr Corporation

Andrew Witkowski

Abhinav Gupta

Mohamed Ziauddin

Sankar Subramanian

Hassan Chafi

Sungpack Hong

Laurent Daynes

Vlad Ioan Haprian

Srikanth Bellamkonda

Tolga Bozkaya

Hugo Kapp

Zhen Hua Liu

Marco Arnaboldi

Lei Sheng

Randall G Bello

Rafi Ahmed

Jean-Pierre Lozi

Sabina Petride

Huagang Li

Nathaniel Keith Folkert

You Jung Kim

Gregory Dorman

Nathan K Folkert

Yossi Matias

Tirthankar Lahiri

Karl Dias

Bhaskar Ghosh

Zhe Wu

Phillip B Gibbons

Martin Roth

Angela Amor

David Greenfield

James Finnerty

Srikanth Ballamkonda

Thierry Cruanes

Amit Ganesh

Juan R Loaiza

Allison Waingold Lee

Shasank Kisan Chavan

Mohamed Zait

Viswanath Poosala

Cetin Ozbutun

Hakan Jakobsson

Beda Christoph Hammerschmidt

Unmesh Jagtap

Ajit Mylavarapu

Ari Wolfe Mozes

Teck Hua Lee

Sujatha Muthulingam

Ekrem Soylemez

Hariharan Lakshmanan

Yali Zhu

Fei Ge

Tsae-Feng Yu

Praveen T J Kumar

Matthew Dombroski

Manish Pratap Singh

Allison Waingold

Ioannis Alagiannis

Srikanth Bondalapati

Aman Namait

Madhuri Kandepi

Yu Chieh Fu

Janaki Latha Lahorani

Venkatesh Sakamuri

Luping Ding

Hari Sankar Sivarama Subramaniyan

Sooyeon Jo

Gerald Venzl

Vicente Hernandez Jimenez

Fred Zemke

Techniques are provided for optimizing storage of database records in segments using sub-segments. A base segment is a container used for storing records that belong to a database object. A database management system receives a request to load, into the database object, a first set of records that are in a first state. In response to receiving the request, the system generates a new sub-segment, which is a container that is separate from the base segment. The system stores the first set of records, in their first state, within the sub-segment. The system then monitors one or more characteristics of the database system. In response to the one or more characteristics satisfying criteria, the system performs a migration of one or more records of the first set of records from the sub-segment to the base segment. During the migration, the system converts the one or more records from the first state to a second state and stores the one or more records, in their second state, in the base segment.

Automatic, online and space efficient clustering and compression of very large database objects

A breadth first search (BFS) algorithm is provided that uses out-of-core external storage in a memory constrained system. Memory resources are used as long as they are available and external storage is used when necessary due to memory pressure. The BFS algorithm uses a disk-spilling hash-table (DSH) as the visited set and disk-spilling queues (DSQs) as the BFS frontier queue. To get the most out of the DSH, subsequent inserts and lookups must happen in the same DSH partition. To ensure that consecutive lookups happen in the same DSH partition, the BFS frontier queue is partitioned in a manner similar to the DSH partitions.

Out-of-core BFS for shortest path graph queries

Disclosed herein are techniques for storing, within a database system, metadata that indicates an intended usage (IU). Once created, an IU may be assigned to a column to (a) indicate how the column is intended to be used, and (b) affect how the database server behaves when database operations involve values from the column. The IU assigned to a column supplements, but does not replace, the datatype definition for the column. Each IU may have an IU-bundle. The IU-bundle of an IU indicates how the database server behaves with respect to any column that is assigned the IU. For example, the IU-bundle may indicate constraints that the database server must validate during operations on values from columns assigned to the IU. Techniques are also described for implementing multi-column IUs and flexible IUs.

Extending database data with intended usage information

Techniques support graph pattern matching queries inside a relational database management system (RDBMS) that supports SQL execution. The techniques compile a graph pattern matching query that includes a bounded recursive pattern query into a SQL query that can then be executed by the relational engine. As a result, techniques enable execution of graph pattern matching queries that include bounded recursive patterns on top of the relational engine by avoiding any change in the existing SQL engine.

Efficient compilation of bounded recursive graph queries on top of SQL based relational engine

In one technique, a definition of a materialized view is identified. Based on the definition, multiple candidate partitioning schemes are identified. A query is generated that indicates one or more of the candidate partitioning schemes. The query is then executed, where executing the query results in one or more partition counts, each corresponding to a different candidate partitioning scheme of the one or more candidate partitioning schemes. Based on the one or more partition counts, a candidate partitioning scheme is selected from among the plurality of candidate partitioning schemes. The materialized view is automatically partitioned based on the candidate partitioning scheme.

Automatic partitioning of materialized views

An RDBMS specifies a graph algorithm function (GAF) that takes a graph object as input and returns a logical graph object as output. GAFs are used within graph queries to compute temporary and output properties ('GAF-computed properties'), which are live for the duration of the query cursor execution. GAF-computed output properties are accessible in the enclosing graph pattern matching query as though they were part of the input graph object of the GAF. Temporary cursor-duration tables are generated for the query cursor during compilation of a graph query that includes a GAF, and are used to store the GAF-computed properties. Each temporary table corresponds to one of the primary tables of the input graph, and includes, as a foreign key, primary key information from the corresponding primary table.

Using temporary tables to store graph algorithm results for a relational database management system

Techniques support graph pattern matching queries inside a relational database management system (RDBMS) that supports SQL execution. The techniques compile a graph pattern matching query into a SQL query that can then be executed by the relational engine. As a result, techniques enable execution of graph pattern matching queries on top of the relational engine by avoiding any change in the existing SQL engine.

Efficient compilation of graph queries including complex expressions on top of sql based relational engine

Techniques described herein allow a user of an RDBMS to specify a graph algorithm function (GAF) declaration, which defines a graph algorithm that takes a graph object as input and returns a logical graph object as output. A database dictionary stores the GAF declaration, which allows addition of GAFs without changing the RDBMS kernel. GAFs are used within graph queries to compute output properties of property graph objects. Output properties are accessible in the enclosing graph pattern matching query, and are live for the duration of the query cursor execution. According to various embodiments, the declaration of a GAF includes a DESCRIBE function, used for semantic analysis of the GAF, and an EXECUTE function, which defines the operations performed by the GAF. Furthermore, composition of GAFs in a graph query is done by supplying, as the input graph argument of an outer GAF, the result of an inner GAF.

Inline graph algorithm execution with a relational SQL engine

Embodiments generate random walks through a directed graph that is represented in a relational database table. Each row of the graph table represents a directed edge in the graph and includes a source vertex and a destination vertex. Each row is further augmented to (a) indicate the number of outbound edges starting from the destination vertex in the row and (b) include an identifier that distinguishes the edge from other outbound edges starting from the same source vertex. An SQL query may be executed on the augmented graph table. Starting from a source vertex (starting vertex or the destination vertex of the previously selected hop) the query randomly selects a row of the graph table representing one of the outbound edges from the source vertex and adds the selected outbound edge as a row in a random walk table that represents the next hop in the random walk.

Efficient SQL-based graph random walk

Definitions of material views are automatically generated. In general, Automated MV generation identifies a set of candidates MVs by examining a working set of query blocks. Once the candidates are formed, the candidate MVs are further evaluated to calculate a benefit to the candidate MVs. An improved approach for generating a candidate set of MVs is described herein. The improved approach is referred to as the extended covering subexpression technique (ECSE). Under ECSE, various relationships between join sets other than strict equivalence are used to generate new resultant join sets. Such relationships include subset, intersection, superset, and union, which shall be described in further detail below. In some cases, relationships among resultant join sets and initial join sets are considered to generate new resultant join sets. The final resultant join sets are then used to form a candidate set of MVs.

Automatic generation of materialized views

Efficient compilation of graph queries on top of SQL based relational engine

Efficient compilation of graph queries involving long graph query patterns on top of SQL based relational engine

An approach for implementing function semantic based partition-wise SQL execution and partition pruning in a data processing system is provided. The system receives a query directed to a range-partitioned table and determines if operation key(s) of the query include(s) function(s) over the table partitioning key(s). If so, the system obtains a set of values corresponding to each partition by evaluating the function(s) on a low bound and/or a high bound table partitioning key value corresponding to the partition. The system may then compare the sets of values corresponding to different partitions and determine whether to aggregate results obtained by executing the query over the partitions based on the comparison. The system may also determine whether to prune any partitions from processing based on a set of correlations between the set of values for each partition and predicate(s) of the query including function(s) over the table partitioning key(s).

Function semantic based partition-wise SQL execution and partition pruning

Techniques are described for storing and maintaining, in a materialized view, bitmap data that represents a bitmap of each possible distinct value of an expression and rewriting a query for a count of distinct values of the expression using the materialized view. The materialized view contains bitmap data that represents a bitmap of each possible distinct value of a first expression, and aggregate values of additional expressions, and is stored in memory or on disk by a database system. The database system receives a query that requests a number of distinct values, of the first expression, and an aggregate value for an additional expression. In response, the database system, rewrites the query to: compute the number of distinct values by counting the bits in the bitmap data of the materialized view that are set to the first value, and obtains the aggregate value for the additional expression in the materialized view.

Bitmap-based count distinct query rewrite in a relational SQL algebra

Growing community of inventors

Foster City, CA, United States of America

Andrew Witkowski