Abstract: A data platform including an error handling framework for loading of input data. The data platform generates input data columns based on an input file and generates result data columns based on the input data columns and evaluating expressions. The data platform detects projection errors during the generating of the result data columns and stores result error indicators in error indicator arrays of the result data columns based on the projection errors. The data platform generates filtered result data columns based on the result data columns and the result error indicator arrays of the result data columns and stores the filtered result data columns in a database of the data platform.

Abstract: The subject technology receives, at a first execution node, a first transaction, the first transaction to be executed on linearizable storage. The subject technology determines whether the first execution node corresponds to a rank indicating a leader worker. The subject technology, in response to the first execution node corresponding to the rank indicating the leader worker, performs, by the first execution node, an initialization process for executing the first transaction. The subject technology broadcasts a first read timestamp associated with the first transaction to a set of execution nodes, the set of execution nodes being different than the first execution node. The subject technology executes, by the first execution node, at least a first operation from the first transaction.

Abstract: The subject technology receives, at a first execution node, a first transaction, the first transaction to be executed on linearizable storage. The subject technology determines whether the first execution node corresponds to a rank indicating a leader worker. The subject technology, in response to the first execution node corresponding to the rank indicating the leader worker, performs, by the first execution node, an initialization process for executing the first transaction. The subject technology broadcasts a first read timestamp associated with the first transaction to a set of execution nodes, the set of execution nodes being different than the first execution node. The subject technology executes, by the first execution node, at least a first operation from the first transaction.

Abstract: Sub-plans are executed in parallel using a plurality of execution nodes, which can be part of a data platform. In particular, various embodiments identify sub-plans (e.g., fragments or portions of one or more child operators) of a root operator in a query plan such that the identified sub-plans that are candidates for execution on a single execution node, determine a cost estimate for causing the candidate sub-plans to be executed in parallel using multiple execution nodes, and cause the candidate sub-plans to be executed in parallel based on the cost estimate.

Abstract: A top K query directed at a table is received. The table is organized into multiple storage units. The top K query comprises a first clause to sort a result set in order and a second clause that specifies a limit on a number of results provided in response to the query. A table scan operator identifies a first set of rows from the table based on a scan set determined for the table and provides the first set of rows to a top K operator. The top K operator determines a current boundary based on the first set of rows and provides the current boundary to the table scan operator. The table scan operator prunes the scan set based on the current boundary and identifies a second set of rows from the table based on the pruning.

Abstract: Methods, systems, and computer programs are presented for scheduling and executing request plans using an opportunistic approach. An opportunistic scheduler generates a request plan for a request on a cloud data platform, the request plan comprising a plurality of operations and identifies a plurality of contingent operations from the plurality of operations of the request plan. The opportunistic scheduler schedules the plurality of contingent operations for execution and sets the scheduled plurality of contingent operations to execute at a specific position in the request plan. The opportunistic scheduler sets remaining operations for execution by any available thread as threads that are processing the request plan become available and processes the request plan according to the scheduled plurality of contingent operations.

Abstract: Various embodiments provide for executing sub-plans in parallel using a plurality of execution nodes, which can be part of a data platform. In particular, various embodiments identify sub-plans (e.g., fragments or portions of one or more child operators) of a root operator in a query plan such that the identified sub-plans that are candidates for execution on a single execution node, determine a cost estimate for causing the candidate sub-plans to be executed in parallel using multiple execution nodes, and cause the candidate sub-plans to be executed in parallel based on the cost estimate.

Abstract: A database scheduler system can be implemented on a distributed database system. The system schedules operations in a lightweight approach that reduces idling and increases parallel processing of database operations for a query on data of the database. The system performs restarts of individual operators or fragments of a query without restarting the entire query.

Abstract: A query directed at a table organized into a set of batch units is received. The query comprises a predicate for which values are unknown prior to runtime. A set of values for the predicate are determined based on the query. An index access plan is created based on the set of values. Based on the index access plan, the set of batch units are pruned using a pruning index associated with the table. The pruning index comprises a set of filters that index distinct values in each column of the table. The pruning of the set of batch units comprises identifying a subset of batch units to scan for data that satisfies the query. The subset of batch units of the table are scanned to identify data that satisfies the query.

Abstract: A global and local row count limit associated with a limit query are received by a stop operator of a first execution node among a set of execution nodes that are assigned to process the limit query. Local distributed row count data is generated based on a local row count corresponding to a number of rows output by the first execution node in processing the query. Based on determining the local row count satisfies the local limit, the first execution node buffers rows produced in processing the query. The local distributed row count data is updated based on remote distributed row count data received from a second execution node. A stopping condition is detected based on determining the global limit is satisfied based on updated local distributed row count data and query processing by the first execution node based on detecting the stopping condition.

Abstract: A query directed at a table organized into a set of batch units is received. The query comprises a predicate for which values are unknown prior to runtime. A set of values for the predicate are determined based on the query. An index access plan is created based on the set of values. Based on the index access plan, the set of batch units are pruned using a pruning index associated with the table. The pruning index comprises a set of filters that index distinct values in each column of the table. The pruning of the set of batch units comprises identifying a subset of batch units to scan for data that satisfies the query. The subset of batch units of the table are scanned to identify data that satisfies the query.

Abstract: A global and local row count limit associated with a limit query are received by a stop operator of a first execution node among a set of execution nodes that are assigned to process the limit query. Local distributed row count data is generated based on a local row count corresponding to a number of rows output by the first execution node in processing the query. Based on determining the local row count satisfies the local limit, the first execution node buffers rows produced in processing the query. The local distributed row count data is updated based on remote distributed row count data received from a second execution node. A stopping condition is detected based on determining the global limit is satisfied based on updated local distributed row count data and query processing by the first execution node based on detecting the stopping condition.

Abstract: Sub-plans are executed in parallel using a plurality of execution nodes, which can be part of a data platform. In particular, sub-plans (e.g., fragments or portions of one or more child operators) of a root operator are identified in a query plan such that the identified sub-plans that are candidates for execution on a single execution node, determine a cost estimate for causing the candidate sub-plans to be executed in parallel using multiple execution nodes, and cause the candidate sub-plans to be executed in parallel based on the cost estimate.

Abstract: A query directed at a table organized into a set of batch units is received. The query comprises a predicate for which values are unknown prior to runtime. A set of values for the predicate are determined based on the query. An index access plan is created based on the set of values. Based on the index access plan, the set of batch units are pruned using a pruning index associated with the table. The pruning index comprises a set of filters that index distinct values in each column of the table. The pruning of the set of batch units comprises identifying a subset of batch units to scan for data that satisfies the query. The subset of batch units of the table are scanned to identify data that satisfies the query.

Abstract: A global and local row count limit associated with a limit query are received by a stop operator of a first execution node among a set of execution nodes that are assigned to process the limit query. Local distributed row count data is generated based on a local row count corresponding to a number of rows output by the first execution node in processing the query. Based on determining the local row count satisfies the local limit, the first execution node buffers rows produced in processing the query. The local distributed row count data is updated based on remote distributed row count data received from a second execution node. A stopping condition is detected based on determining the global limit is satisfied based on updated local distributed row count data and query processing by the first execution node based on detecting the stopping condition.

Abstract: A query directed at a table organized into a set of batch units is received. The query comprises a predicate for which values are unknown prior to runtime. A set of values for the predicate are determined based on the query. An index access plan is created based on the set of values. Based on the index access plan, the set of batch units are pruned using a pruning index associated with the table. The pruning index comprises a set of filters that index distinct values in each column of the table. The pruning of the set of batch units comprises identifying a subset of batch units to scan for data that satisfies the query. The subset of batch units of the table are scanned to identify data that satisfies the query.

Abstract: A global and local row count limit associated with a limit query are received by a stop operator of a first execution node among a set of execution nodes that are assigned to process the limit query. Local distributed row count data is generated based on a local row count corresponding to a number of rows output by the first execution node in processing the query. Based on determining the local row count satisfies the local limit, the first execution node buffers rows produced in processing the query. The local distributed row count data is updated based on remote distributed row count data received from a second execution node. A stopping condition is detected based on determining the global limit is satisfied based on updated local distributed row count data and query processing by the first execution node based on detecting the stopping condition.

Abstract: A global and local row count limit associated with a limit query are received by a stop operator of a first execution node among a set of execution nodes that are assigned to process the limit query. Local distributed row count data is generated based on a local row count corresponding to a number of rows output by the first execution node in processing the query. Based on determining the local row count satisfies the local limit, the first execution node buffers rows produced in processing the query. The local distributed row count data is updated based on remote distributed row count data received from a second execution node. A stopping condition is detected based on determining the global limit is satisfied based on updated local distributed row count data and query processing by the first execution node based on detecting the stopping condition.

Abstract: A global and local row count limit associated with a limit query are received by a stop operator of a first execution node among a set of execution nodes that are assigned to process the limit query. Local distributed row count data is generated based on a local row count corresponding to a number of rows output by the first execution node in processing the query. Based on determining the local row count satisfies the local limit, the first execution node buffers rows produced in processing the query. The local distributed row count data is updated based on remote distributed row count data received from a second execution node. A stopping condition is detected based on determining the global limit is satisfied based on updated local distributed row count data and query processing by the first execution node based on detecting the stopping condition.

Abstract: A global and local row count limit associated with a limit query are received by a stop operator of a first execution node among a set of execution nodes that are assigned to process the limit query. Local distributed row count data is generated based on a local row count corresponding to a number of rows output by the first execution node in processing the query. Based on determining the local row count satisfies the local limit, the first execution node buffers rows produced in processing the query. The local distributed row count data is updated based on remote distributed row count data received from a second execution node. A stopping condition is detected based on determining the global limit is satisfied based on updated local distributed row count data and query processing by the first execution node based on detecting the stopping condition.