CONCURRENT BEGIN...END

Executes multiple SQL statements concurrently within a single block, providing cooperative parallelism with run-all-report-all semantics and a per-statement summary result set.

Syntax

CONCURRENT BEGIN
  <statement1>;
  <statement2>;
  ...
END

Description

## Overview CONCURRENT BEGIN...END groups multiple SQL statements for simultaneous execution. All statements within the block run concurrently using cooperative async parallelism; the block completes when every statement has finished. A summary result set reports the status, timing, row count, and error message for each statement. ## Behavior The parser splits the block content on semicolons at depth zero, respecting nested BEGIN/END pairs and parenthesized subexpressions. Each extracted statement is dispatched as an independent future through the full execution pipeline via `futures::future::join_all`. Execution follows run-all-report-all semantics: if one statement fails, the remaining statements continue to completion. This differs from sequential execution where a failure would halt the script. After all statements finish, the executor builds a summary RecordBatch with columns: - **index** (INT64): One-based statement ordinal. - **status** (UTF8): "OK" or "ERROR". - **sql** (UTF8): The original SQL text of the statement. - **message** (UTF8): The execution message (e.g., rows affected). - **rows** (INT64, nullable): Row count from the result or rows_affected metric. - **time_ms** (INT64): Wall-clock execution time for that statement. - **error** (UTF8): Error message if status is "ERROR"; empty otherwise. The block's overall message reports whether all statements succeeded or some failed, along with the total wall-clock time. ### Concurrency Model Statements execute as cooperative async tasks on the Tokio runtime. They share the same executor context (session, catalog, table registry), so they can read from the same registered tables. For I/O-bound SQL queries, this provides near-identical throughput to OS-thread-level parallelism because concurrency occurs at async .await points during file reads and network calls. ## Compatibility CONCURRENT BEGIN...END is a DeltaForge extension with no equivalent in standard SQL. Standard BEGIN...END blocks execute sequentially. The CONCURRENT keyword signals parallel dispatch.

Parameters

Name	Type	Description
statements		One or more SQL statements separated by semicolons. Each statement runs as an independent concurrent task through the full execution pipeline (including table registration, Cypher resolution, macro expansion, and Delta commands). Statements are split on semicolons at depth zero; nested BEGIN/END blocks and parenthesized expressions are respected and do not trigger premature splitting. The block must contain at least one statement.

Examples

-- Run two independent queries in parallel
CONCURRENT BEGIN
    SELECT COUNT(*) FROM warehouse.sales.orders;
    SELECT COUNT(*) FROM warehouse.sales.customers;
END

-- Parallel data loading into separate target tables
CONCURRENT BEGIN
    INSERT INTO gold.summary.daily_orders
    SELECT order_date, COUNT(*) AS cnt
    FROM silver.sales.orders
    GROUP BY order_date;

    INSERT INTO gold.summary.daily_revenue
    SELECT order_date, SUM(amount) AS total
    FROM silver.sales.orders
    GROUP BY order_date;
END

-- Combine assertions and queries concurrently
CONCURRENT BEGIN
    ASSERT ROW_COUNT > 0
    SELECT * FROM warehouse.sales.orders WHERE order_date = CURRENT_DATE;

    ASSERT ROW_COUNT > 0
    SELECT * FROM warehouse.inventory.products WHERE stock > 0;
END

-- Parallel maintenance operations on different tables
CONCURRENT BEGIN
    OPTIMIZE warehouse.sales.orders;
    OPTIMIZE warehouse.sales.customers;
    OPTIMIZE warehouse.inventory.products;
END

Pitfalls

• All statements share the same session context. Concurrent writes to the same Delta table may produce transaction conflicts. Use CONCURRENT blocks for independent tables or read-only queries to avoid contention.
• An empty CONCURRENT block (no statements between BEGIN and END) produces a parse error. At least one statement is required.
• Error handling follows run-all-report-all semantics: a single statement failure does not abort the remaining statements. Check the summary result set for per-statement status to identify partial failures.

See Also

• ASSERT