Snowflake Inc.

Sebastian Breß

Max Heimel

Moritz Eyssen

Max Jendruk

Matthias Carl Adams

Bjoern Daase

Florian Andreas Funke

Georg Ortwin Otto Kissig

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

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 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

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

Sebastian Breß