Abstract: A system includes a database having one or more tables having multiple partitions. The database includes memory modules to store the multiple partitions, a query processor, a data manipulation language (DML) processor configured to process operations to manipulate data in one or more of the partitions and a statistics module. For each partition, the statistics module maintains a partition profile and stores the partition profile in a statistics cache. The partition profile includes at least a first interval of data range values per column for one or more columns. The statistics module updates at least the first interval of a partition profile for a partition with new data range values responsive to the DML processor processing an operation to manipulate data in the partition. The database includes a partition pruning module that is configured to include partitions responsive to a received query based on the partition profile.

Abstract: 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.

Abstract: A node type of a plurality of distributed nodes to which a table to be added to a distributed database should be assigned can be identified by applying a set of placement rules defined for the table. The set of placement rules can also be applied to determine whether the table should be partitioned into more than one partition. A table group name associated with the table can be obtained and used in conjunction with the node type and determination of whether to partition the table to store the table in the distributed database on at least one node of the plurality of nodes as one or more partitions.

Abstract: 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.

Abstract: A dynamic split node defined within a calculation model can receive data being operated on by a calculation plan generated based on the calculation model. A partition specification can be applied to one or more reference columns in a table containing at least some of the received data. The applying can cause the table to be split such that a plurality of records in the table are partitioned according to the partition specification. A separate processing path can be set for each partition, and execution of the calculation plan can continue using the separate processing paths, each of which can be assigned to a processing node of a plurality of available processing nodes.

Abstract: A system for hash collision tables for relational operations is provided. In some implementations, the system performs operations comprising generating a plurality of hash values for at least a portion of one or more database tables based on a database query, and generating a hash table for at least a portion of the plurality of hash values. The operations can further include generating first results based on execution of a first operation in the database query using the hash table. Additionally, the operations can further include generating second results based on the first results and execution of a second operation in the database query using the hash table. Related systems, methods, and articles of manufacture are also described.

Abstract: 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.

Abstract: A method can include: generating a query execution plan for a query including a plurality of operations that operate on data from a relational database and data from a non-structured query language (NoSQL) database, the generating comprising optimizing the query by: identifying a first operation that operate on data from the relational database and an intermediate result output by a second operation, the second operation outputting the intermediate result by operating on the data from the NoSQL database; and determining a fixed datatype for the intermediate result, an indication of the fixed datatype being included in the query execution plan; and executing, based on the query execution plan, the query, the executing of the query comprising converting the intermediate result to the fixed datatype, the converting enabling the first operation to operate on the intermediate result output by the second operation along with the data from the relational database.

Abstract: Methods, systems, and computer-readable storage media for determining that a transaction of a plurality of transactions performed in at least a portion of a system includes a delete operation, the plurality of transactions being managed by a secondary transaction manager and including a subset of all transactions performed in the system, in response to the delete operation, inserting a clean-up entry in the secondary transaction manager, attaching the clean-up entry to a subsequent transaction in order to determine and assign a time to the cleanup-entry that is used to subsequently trigger garbage collection, and selectively comparing the time to a most-recently-reported minimum read timestamp that is periodically reported to the secondary transaction manager from a primary transaction manager of the system, wherein the clean-up entry is executed in response to determining that the time is less than the most-recently-reported minimum read timestamp.

Abstract: Partitioning of a source table of a database to a target table is initiated. Thereafter, a replay table is generated that is populated with triggers for database operations performed on the source table for subsequent replay for the target partitions. Data is later moved (e.g., asynchronously moved, etc.) from the source table to the target table. The database operations are replayed on the target table T subsequent to the moving of the data using the replay table. In addition, the source table is dropped when all of the data has been moved to the target table and there are no operations requiring replay. Related apparatus, systems, techniques and articles are also described.

Abstract: Technologies are described for facilitating database system recovery in a distributed database environment having a master node and at least one slave node. The master node maintains an in-memory reference that includes transaction identifiers and their corresponding commit identifiers. When a slave node requests that a commit identifier be assigned to a transaction, the transaction and commit identifiers for the transaction are added to the in-memory reference. The commit identifier is sent by the master node to the slave node. The slave node writes a log entry to a commit log that includes the transaction identifier and the assigned commit identifier. If the database system is interrupted before the slave node writes the commit log entry, the slave node can request the commit identifier for the transaction from the master node, which retrieves the identifier from the in-memory reference.

Abstract: Partitioning of source partitions of a table of a database to target partitions is initiated. Thereafter, a transition partition specification is specified that identifies the source partitions and the target partitions. Data is then moved (e.g., asynchronously moved, etc.) from the source partitions to the target partitions. Concurrently with the moving of the data, operates are handled using the transition partition specification. Subsequently, the source partitions are dropped when all of the data has been moved to the target partitions and there are no open transactions accessing the source partitions. Related apparatus, systems, techniques and articles are also described.

Abstract: A first store and a second store can be configured to store a first partition of a table of a database and a second partition of the table of the database, respectively. A database management system can be configured to at least update at least a first portion of the first partition where the update includes an update to a first primary key column in the first partition and verify that the first primary key column is unique across the first partition and the second partition. A first row having a first primary key value of the first primary key column from the first partition can be deleted, when the first primary key value in the first partition conflicts with a second primary key value of a second primary key column in the second partition.

Abstract: A table creation request pertaining to a table in a database maintained on a multi-node data partitioning landscape that comprises a plurality of processing nodes can specify a number of partitions to be generated. At run time, a currently available number of processing nodes in the multi-node data partitioning landscape can be queried, and this currently available number of processing nodes can be compared with the specified number of partitions to be generated for the created table. The table can be generated with the specified number of partitions such that the generated partitions are located across the plurality of partitions according to a load balancing approach if the number of processing nodes equals the number of partitions to be generated or according to other information in the table request if the number of processing nodes does not equal the specified number of partitions.

Abstract: A query is received from a client that specifies at least one database operation implicating data within a first database and within a second database. The first database can have a first transaction manager and the second database can have a second transaction manager. Thereafter, a plurality of transactions responsive to the query are initiated to access the data within the first database and the second database. Execution of the plurality of transactions is then coordinated using the first transaction manager and the second transaction manager. All changes specified by the at least one database operation are logged in a distributed log in the first database including changes implicating data stored within the second database. The distributed log is configured such that it is accessible by both of the first transaction manager and the second transaction manager.

Abstract: A query is received from a client that specifies at least one database operation implicating data within a first database and within a second database. The first database has a first transaction manager and the second database has a second transaction manager. Thereafter, a plurality of transactions responsive to the query are initiated to access the data within the first database and the second database. Execution of the plurality of transactions are coordinated using the first transaction manager such that commits for both of the first database and the second database are handled by the first transaction manager. Data responsive to the query can then be provided to the client. Related apparatus, systems, techniques and articles are also described.

Abstract: Disclosed herein are system, method, and computer program product embodiments for incrementally building hash collision tables. In some embodiments, hashes and hash collision tables may be used to improve efficiency of relational operations, such as those used in relational databases. An embodiment operates by determining hash collisions between data entries, then storing newly determined hash values corresponding to collisions in a hash collision table. The storing can be done incrementally, without needing to rebuild hash tables or hash collision tables for all data entries.

Abstract: Disclosed herein are system, method, and computer program product embodiments for incrementally building hash collision tables. In some embodiments, hashes and hash collision tables may be used to improve efficiency of relational operations, such as those used in relational databases. An embodiment operates by determining hash collisions between data entries, then executing a join operation referencing the hash table and the hash collision table to produce a result set.

Abstract: A database system can receive, from a client, a query specifying at least one database operation implicating data within a first database and within a second database. The first database can have a first transaction manager and the second database can have a second transaction manager. Thereafter, a plurality of transactions are initiated that are responsive to the query to access the data within the first database and the second database. The first transaction manager and the second transaction manager together coordinate execution of the plurality of transactions. All changes specified by the at least one database operation are persisted in persistence of the first database including changes implicating data stored within the second database. Data responsive to the query can then optionally be provided to the client. Related apparatus, systems, techniques and articles are also described.

Abstract: A system for encoding and/or decoding documents for a document store is provided. In some implementations, the system performs operations comprising receiving a query related to at least a portion of a plurality of stored documents and retrieving one or more documents from the plurality of stored documents based on the query. The operations can further include generating a client-side dictionary including a plurality of definitions corresponding to a plurality of parameters (e.g., reference values for corresponding parameters) from the plurality of stored documents. The operations can also include providing the client-side dictionary and the one or more documents in response to the query. One or more of the operations can be implemented by a database server. Related systems, methods, and articles of manufacture are also described.