Abstract: A method may include receiving a first transaction inserting a record into a database and a second transaction deleting the record from the database. A validity period for the record may be determined based on a first commit time at which the first transaction is committed and a second commit time at which the second transaction is committed. A current table and/or a history table of a system versioned table may be updated to include the record based on the validity period of the record. One or more temporal operations may be performed based on the system versioned table. For example, a time travel operation may be performed to retrieve, based on the system versioned table, one or more records that are valid at a given point in time. Related systems and computer program products are also provided.

Abstract: A method may include receiving a first transaction inserting a record into a database and a second transaction deleting the record from the database. A validity period for the record may be determined based on a first commit time at which the first transaction is committed and a second commit time at which the second transaction is committed. A current table and/or a history table of a system versioned table may be updated to include the record based on the validity period of the record. One or more temporal operations may be performed based on the system versioned table. For example, a time travel operation may be performed to retrieve, based on the system versioned table, one or more records that are valid at a given point in time. Related systems and computer program products are also provided.

Abstract: A method may include receiving a first transaction inserting a record into a database and a second transaction deleting the record from the database. A validity period for the record may be determined based on a first commit time at which the first transaction is committed and a second commit time at which the second transaction is committed. A current table and/or a history table of a system versioned table may be updated to include the record based on the validity period of the record. One or more temporal operations may be performed based on the system versioned table. For example, a time travel operation may be performed to retrieve, based on the system versioned table, one or more records that are valid at a given point in time. Related systems and computer program products are also provided.

Abstract: Disclosed herein are system, method, and computer program product embodiments for managing timestamp information in memory systems. In an embodiment, an infrastructure may utilize a controller to manage sparse timestamp blocks. These sparse timestamp blocks may manage timestamp information in a persistent memory structure. Controller 110 may utilize a transient timestamp accessor to map the timestamp information for faster hash lookups. Controller 110 may also utilize a garbage collection map as a bitmap to further save processing steps. Controller 110 may utilize the sparse timestamp blocks, transient timestamp accessor, and garbage collection map to efficiently store timestamp data and to quickly retrieve the stored timestamp data.

Abstract: Restoring of a database table in the database system (e.g., an in-memory insert-only database system, etc.) is initiated. Thereafter, a transaction log volume storing data log records and multi-version concurrency control (MVCC) log records corresponding to the database table is accessed. Based on such access, data log records corresponding to the database table are replayed while insert and update MVCC log records corresponding to the database table are skipped. Subsequently, restoring of the database table in the database system is finalized. Related apparatus, systems, techniques and articles are also described.

Abstract: Disclosed herein are system, method, and computer program product embodiments for managing timestamp information in memory systems. In an embodiment, an infrastructure may utilize a controller to manage sparse timestamp blocks. These sparse timestamp blocks may manage timestamp information in a persistent memory structure. Controller 110 may utilize a transient timestamp accessor to map the timestamp information for faster hash lookups. Controller 110 may also utilize a garbage collection map as a bitmap to further save processing steps. Controller 110 may utilize the sparse timestamp blocks, transient timestamp accessor, and garbage collection map to efficiently store timestamp data and to quickly retrieve the stored timestamp data.

Abstract: A system for implementing virtual columns in a column store database is provided. In some implementations, the system performs operations including accessing a database table in a column store database system, the database table comprising at least one virtual column, the column store database system storing data in a column-oriented structure. The operations further include calculating a value for the at least one virtual column based on at least one existing column of the database table, the calculated value mapped to a row identifier associated with a row of the database table. The operations further include providing, in response to a query, the calculated value to a user interface, the query associated with the row identifier.

Abstract: Disclosed herein are system, method, and computer program product embodiments for performing database processing after a lock condition. An embodiment operates by receiving a release of a lock on data of a database. It is determined whether the data was modified by a processing of a first transaction associated with the first request. The lock is provided to a second transaction associated with a second request to access the data. If the first transaction did not modify the data, a second transaction associated with the second request is retried without refreshing a snapshot of the data. If the first transaction modified the data, the snapshot of the data is refreshed before the second transaction is retried.

Abstract: Disclosed herein are system, method, and computer program product embodiments for managing timestamp information in memory systems. In an embodiment, an infrastructure may utilize a controller to manage sparse timestamp blocks. These sparse timestamp blocks may manage timestamp information in a persistent memory structure. Controller 110 may utilize a transient timestamp accessor to map the timestamp information for faster hash lookups. Controller 110 may also utilize a garbage collection map as a bitmap to further save processing steps. Controller 110 may utilize the sparse timestamp blocks, transient timestamp accessor, and garbage collection map to efficiently store timestamp data and to quickly retrieve the stored timestamp data.

Abstract: An operation on a row of a table of a database is initiated. Thereafter, a multi-version concurrency control (MVCC) object is accessed to identify blocks associated with the row position of the row using bitwise operations. Subsequently, a row state block computed based on the row position of the row is accessed to determine a row state for the row. At least one other block is accessed, based in part on the row state, to obtain at least one timestamp from the computed offset based on the row. Next, the at least one timestamp is stored or retrieved. Related apparatus, systems, techniques and articles are also described.

Abstract: Calculation of aggregated values in a history database table can be optimized using an approach in which an ordered history table is accessed. The ordered history table can include a sequential listing of commit identifiers associated with updates, insertions, and/or deletions to values in the database table. The ordered history table can be traversed in a single pass to calculate an aggregation function using an optimized algorithm. The optimized algorithm can enable calculation of an aggregated metric of the values based on a selected method for tracking invalidated values to their corresponding commit identifiers. The calculated metric is generated for a current version of the database table; and promoted.

Abstract: Disclosed herein are system, method, and computer program product embodiments for managing timestamp information in memory systems. In an embodiment, an infrastructure may utilize a controller to manage sparse timestamp blocks. These sparse timestamp blocks may manage timestamp information in a persistent memory structure. Controller 110 may utilize a transient timestamp accessor to map the timestamp information for faster hash lookups. Controller 110 may also utilize a garbage collection map as a bitmap to further save processing steps. Controller 110 may utilize the sparse timestamp blocks, transient timestamp accessor, and garbage collection map to efficiently store timestamp data and to quickly retrieve the stored timestamp data.

Abstract: An update to a partitioning column for a partitioned table in a database can be performed by handling rows for which the update will not require moving to a different partition separately (e.g. “locally”) for each partition followed by re-inserting those rows that will require moving to a different partition and deleting them from the original partition. The re-inserted rows are directed to a correct partition by application of the partitioning criteria for the table. Methods, articles, and systems are described.

Abstract: A system for implementing virtual columns in a column store database is provided. In some implementations, the system performs operations including accessing a database table in a column store database system, the database table comprising at least one virtual column, the column store database system storing data in a column-oriented structure. The operations further include calculating a value for the at least one virtual column based on at least one existing column of the database table, the calculated value mapped to a row identifier associated with a row of the database table. The operations further include providing, in response to a query, the calculated value to a user interface, the query associated with the row identifier.

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: Restoring of a database table in the database system (e.g., an in-memory insert-only database system, etc.) is initiated. Thereafter, a transaction log volume storing data log records and multi-version concurrency control (MVCC) log records corresponding to the database table is accessed. Based on such access, data log records corresponding to the database table are replayed while insert and update MVCC log records corresponding to the database table are skipped. Subsequently, restoring of the database table in the database system is finalized. Related apparatus, systems, techniques and articles are also described.

Abstract: Calculation of aggregated values in a history database table can be optimized using an approach in which an ordered history table is accessed. The ordered history table can include a sequential listing of commit identifiers associated with updates, insertions, and/or deletions to values in the database table. The ordered history table can be traversed in a single pass to calculate an aggregation function using an optimized algorithm. The optimized algorithm can enable calculation of an aggregated metric of the values based on a selected method for tracking invalidated values to their corresponding commit identifiers. The calculated metric is generated for a current version of the database table; and promoted.

Abstract: Calculation of aggregated values in a history database table can be optimized using an approach in which an ordered history table is accessed. The ordered history table can include a sequential listing of commit identifiers associated with updates, insertions, and/or deletions to values in the database table. The ordered history table can be traversed in a single pass to calculate an aggregation function using an optimized algorithm. The optimized algorithm can enable calculation of an aggregated metric of the values based on a selected method for tracking invalidated values to their corresponding commit identifiers. The calculated metric is generated for a current version of the database table; and promoted.

Abstract: An update to a partitioning column for a partitioned table in a database can be performed by handling rows for which the update will not require moving to a different partition separately (e.g. “locally”) for each partition followed by re-inserting those rows that will require moving to a different partition and deleting them from the original partition. The re-inserted rows are directed to a correct partition by application of the partitioning criteria for the table. Methods, articles, and systems are described.

Abstract: Disclosed herein are system, method, and computer program product embodiments for performing database processing after a lock condition. An embodiment operates by receiving a release of a lock on data of a database. It is determined whether the data was modified by a processing of a first transaction associated with the first request. The lock is provided to a second transaction associated with a second request to access the data. If the first transaction did not modify the data, a second transaction associated with the second request is retried without refreshing a snapshot of the data. If the first transaction modified the data, the snapshot of the data is refreshed before the second transaction is retried.