Snowflake Inc.

Max Heimel

Moritz Eyssen

Sebastian Breß

Ismail Oukid

Stefan Richter

Juliane K Waack

Linnea Passing

Max Jendruk

Thierry Cruanes

Alexander Miller

Abdullah Al Mahmood

Xin Huang

Lishi Jiang

Ruta Dhaneshwar

Purav B Saraiya

Canzhou Qu

Konstantinos Zoumpatianos

Matthias Carl Adams

Bjoern Daase

Florian Andreas Funke

Sebastian Breβ

Georg Ortwin Otto Kissig

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.

File-based error handling during ingestion with transformation

Provided herein are systems and methods for hash-join broadcast decision making. For example, a method includes generating a query plan for a received query. The query plan includes a plurality of join operations with a plurality of hash-join-build (HJB) operations and a plurality of hash-join-probe (HJP) operations. A decision node of a plurality of decision nodes of the query plan is configured as a primary decision node. Build-side data information associated with build-side data and received from the plurality of HJB operations is decoded by the primary decision node. A data distribution method is determined by the primary decision node for each HJB operation of the plurality of HJB operations based on the build-side data information. The query plan is executed based on distributing the build-side data to the plurality of HJP operations using the data distribution method for each HJB operation of the plurality of HJB operations.

Hash-join broadcast decision making in database systems

A database system configured to optimize query execution through an opportunistic scheduling approach. The database system generates a query plan and identifies a contingent database operation within the query plan, the contingent database operation being dependent on a completion of at least one additional operation. The database system schedules the contingent operation using an opportunistic scheduler. The database system executes the query plan comprising processing the contingent database operation after the completion of the at least one additional operation.

Dynamic database pipeline scheduler

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.

Distributed execution of transactional queries

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.

Query processing using a distributed stop operator

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.

Opportunistic cloud data platform pipeline scheduler

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.

Scheduling parallel execution of query sub-plans

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.

Pruning data based on state of top K operator

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.

Lightweight database pipeline scheduler

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.

Join query processing using pruning index

Distributed stop operator for limit queries

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.

Growing community of inventors

Berlin, Germany

Max Heimel