sqlbenchdag 0.1.0__py3-none-any.whl

sql_benchmarks/scripts/sql/analytical_wall/actian/analytical_wall.sql

@@ -0,0 +1,15 @@
+-- analytical_wall.sql (Actian)
+SELECT 
+    region,
+    category,
+    COUNT(*) as transaction_count,
+    ROUND(CAST(SUM(price * quantity * (1 - discount)) AS numeric), 2) as net_revenue,
+    ROUND(CAST(AVG(price * quantity * (1 - discount)) AS numeric), 2) as avg_transaction_value,
+    ROUND(CAST(SUM(CASE WHEN discount > 0.15 THEN price * quantity ELSE 0 END) / SUM(price * quantity + 0.00001) * 100 AS numeric), 2) as high_discount_impact_pct
+FROM 
+    {{ analytical_data_table }}
+GROUP BY 
+    region, 
+    category
+ORDER BY 
+    net_revenue DESC;

sql_benchmarks/scripts/sql/analytical_wall/analytical_wall.sql.template

@@ -0,0 +1,19 @@
+-- analytical_wall.sql
+-- Goal: Demonstrate Actian's X100 Vectorized Engine vs. Postgres Row-based Execution.
+-- Scenario: Calculating Weighted Net Revenue Across Regions and Categories for 10M+ rows.
+
+SELECT 
+    region,
+    category,
+    COUNT(*) as transaction_count,
+    ROUND(SUM(price * quantity * (1 - discount)), 2) as net_revenue,
+    ROUND(AVG(price * quantity * (1 - discount)), 2) as avg_transaction_value,
+    -- Complex aggregation that forces per-row math
+    ROUND(SUM(CASE WHEN discount > 0.15 THEN price * quantity ELSE 0 END) / SUM(price * quantity + 0.00001) * 100, 2) as high_discount_impact_pct
+FROM 
+    analytical_data
+GROUP BY 
+    region, 
+    category
+ORDER BY 
+    net_revenue DESC;

sql_benchmarks/scripts/sql/analytical_wall/duckdb/analytical_wall.sql

@@ -0,0 +1,15 @@
+-- analytical_wall.sql (DuckDB)
+SELECT 
+    region,
+    category,
+    COUNT(*) as transaction_count,
+    ROUND(SUM(price * quantity * (1 - discount)), 2) as net_revenue,
+    ROUND(AVG(price * quantity * (1 - discount)), 2) as avg_transaction_value,
+    ROUND(SUM(CASE WHEN discount > 0.15 THEN price * quantity ELSE 0 END) / SUM(price * quantity + 0.00001) * 100, 2) as high_discount_impact_pct
+FROM 
+    {{ analytical_data_table }}
+GROUP BY 
+    region, 
+    category
+ORDER BY 
+    net_revenue DESC;

sql_benchmarks/scripts/sql/analytical_wall/postgres/analytical_wall.sql

@@ -0,0 +1,15 @@
+-- analytical_wall.sql (Postgres)
+SELECT 
+    region,
+    category,
+    COUNT(*) as transaction_count,
+    ROUND(CAST(SUM(price * quantity * (1 - discount)) AS numeric), 2) as net_revenue,
+    ROUND(CAST(AVG(price * quantity * (1 - discount)) AS numeric), 2) as avg_transaction_value,
+    ROUND(CAST(SUM(CASE WHEN discount > 0.15 THEN price * quantity ELSE 0 END) / SUM(price * quantity + 0.00001) * 100 AS numeric), 2) as high_discount_impact_pct
+FROM 
+    {{ analytical_data_table }}
+GROUP BY 
+    region, 
+    category
+ORDER BY 
+    net_revenue DESC;

sql_benchmarks/scripts/sql/group_by/duckdb/groupby_antipattern.sql

@@ -0,0 +1,11 @@
+SELECT
+    c.customer_id,
+    c.customer_name,
+    c.region,
+    SUM(o.amount) AS total_spend
+FROM
+    {{ customers_table }} c
+INNER JOIN
+    {{ orders_table }} o ON c.customer_id = o.customer_id
+GROUP BY
+    c.customer_id, c.customer_name, c.region; -- The anti-pattern

sql_benchmarks/scripts/sql/group_by/duckdb/groupby_recommended_cte.sql

@@ -0,0 +1,19 @@
+-- The Recommended CTE Pattern: Aggregate the large table first, then join.
+WITH CustomerSpend AS (
+    SELECT
+        customer_id,
+        SUM(amount) AS total_customer_spend
+    FROM
+        {{ orders_table }}
+    GROUP BY
+        customer_id
+)
+SELECT
+    c.customer_id,
+    c.customer_name,
+    c.region,
+    cs.total_customer_spend
+FROM
+    {{ customers_table }} c
+INNER JOIN
+    CustomerSpend cs ON c.customer_id = cs.customer_id;

sql_benchmarks/scripts/sql/group_by/postgres/groupby_antipattern.sql

@@ -0,0 +1,13 @@
+-- groupby_anti_pattern.sql
+SELECT
+    c.customer_id,
+    c.customer_name,
+    c.region,
+    SUM(o.amount) AS total_amount
+FROM
+    {{ customers_table }} c
+INNER JOIN
+    {{ orders_table }} o ON c.customer_id = o.customer_id
+GROUP BY
+    c.customer_id, c.customer_name, c.region;
+

sql_benchmarks/scripts/sql/group_by/postgres/groupby_recommended_pk.sql

@@ -0,0 +1,11 @@
+SELECT
+    c.customer_id,
+    c.customer_name,
+    c.region,
+    SUM(o.amount) AS total_amount
+FROM
+    {{ customers_table }} c
+JOIN
+    {{ orders_table }} o ON c.customer_id = o.customer_id
+GROUP BY
+    c.customer_id; -- Postgres infers name/region from PK

sql_benchmarks/scripts/sql/hypergraph/duckdb/q_1hop.sql

@@ -0,0 +1,5 @@
+SELECT DISTINCT b.id, b.name, b.region
+FROM {{ supply_contract_table }} sc
+JOIN {{ supplier_table }} s ON s.id = sc.supplier_id
+JOIN {{ buyer_table }} b ON b.id = sc.buyer_id
+WHERE s.country = 'US';

sql_benchmarks/scripts/sql/hypergraph/duckdb/q_2hop.sql

@@ -0,0 +1,6 @@
+SELECT DISTINCT p.id, p.name, p.category
+FROM {{ supply_contract_table }} sc
+JOIN {{ supplier_table }} s ON s.id = sc.supplier_id
+JOIN {{ product_table }} p ON p.id = sc.product_id
+WHERE s.country = 'EU'
+  AND p.category = 'electronics';

sql_benchmarks/scripts/sql/hypergraph/duckdb/q_full.sql

@@ -0,0 +1,9 @@
+SELECT s.id AS supplier_id, s.country,
+       b.id AS buyer_id,    b.region,
+       p.id AS product_id,  p.category
+FROM {{ supply_contract_table }} sc
+JOIN {{ supplier_table }} s ON s.id = sc.supplier_id
+JOIN {{ buyer_table }}    b ON b.id = sc.buyer_id
+JOIN {{ product_table }}  p ON p.id = sc.product_id
+WHERE s.country = 'US'
+  AND b.region  = 'APAC';

sql_benchmarks/scripts/sql/hypergraph/typedb/q_1hop.sql

@@ -0,0 +1,4 @@
+match
+  $s isa {{ supplier_table }}, has country "US";
+  $sc (supplier_role: $s, buyer_role: $b) isa {{ supply_contract_table }};
+select $b;

sql_benchmarks/scripts/sql/hypergraph/typedb/q_2hop.sql

@@ -0,0 +1,5 @@
+match
+  $s isa {{ supplier_table }}, has country "EU";
+  $sc (supplier_role: $s, product_role: $p) isa {{ supply_contract_table }};
+  $p isa {{ product_table }}, has category "electronics";
+select $p;

sql_benchmarks/scripts/sql/hypergraph/typedb/q_full.sql

@@ -0,0 +1,6 @@
+match
+  $sc (supplier_role: $s, buyer_role: $b, product_role: $p) isa {{ supply_contract_table }};
+  $s isa {{ supplier_table }}, has country "US";
+  $b isa {{ buyer_table }}, has region "APAC";
+  $p isa {{ product_table }};
+select $s, $b, $p;

sql_benchmarks/scripts/sql/joins/duckdb/join_antipattern.sql

@@ -0,0 +1,5 @@
+-- This query uses a Left Join and filters NULLs, which is slower than Inner Join
+SELECT count(*) 
+FROM {{ orders_table }} o 
+LEFT JOIN {{ customers_table }} c ON o.customer_id = c.customer_id
+WHERE c.customer_id IS NOT NULL;

sql_benchmarks/scripts/sql/joins/duckdb/join_recommended.sql

@@ -0,0 +1,4 @@
+-- This query uses a standard Inner Join
+SELECT count(*) 
+FROM {{ orders_table }} o 
+JOIN {{ customers_table }} c ON o.customer_id = c.customer_id;

sql_benchmarks/scripts/sql/joins/postgres/join_antipattern.sql

@@ -0,0 +1,5 @@
+-- This query uses a Left Join and filters NULLs, which is slower than Inner Join
+SELECT count(*) 
+FROM {{ orders_table }} o 
+LEFT JOIN {{ customers_table }} c ON o.customer_id = c.customer_id
+WHERE c.customer_id IS NOT NULL;

sql_benchmarks/scripts/sql/joins/postgres/join_recommended.sql

@@ -0,0 +1,4 @@
+-- This query uses a standard Inner Join
+SELECT count(*) 
+FROM {{ orders_table }} o 
+JOIN {{ customers_table }} c ON o.customer_id = c.customer_id;

sql_benchmarks/scripts/sql/null_logic/duckdb/2VL_identity.sql

@@ -0,0 +1,14 @@
+-- 1. Matches for Non-Nulls (Uses Hash Join)
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} = r2.{{ join_key_a }}
+
+UNION ALL
+
+-- 2. Matches for Nulls (Identity)
+-- This is just a cartesian of nulls, but isolated so it doesn't kill the Hash Join
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} IS NULL AND r2.{{ join_key_a }} IS NULL;

sql_benchmarks/scripts/sql/null_logic/duckdb/3VL_identity.sql

@@ -0,0 +1,5 @@
+-- 3VL TEST (Standard Identity Loss)
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} = r2.{{ join_key_a }};

sql_benchmarks/scripts/sql/null_logic/postgres/2VL_identity.sql

@@ -0,0 +1,14 @@
+-- 1. Matches for Non-Nulls (Uses Hash Join)
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} = r2.{{ join_key_a }}
+
+UNION ALL
+
+-- 2. Matches for Nulls (Identity)
+-- This is just a cartesian of nulls, but isolated so it doesn't kill the Hash Join
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} IS NULL AND r2.{{ join_key_a }} IS NULL;

sql_benchmarks/scripts/sql/null_logic/postgres/3VL_identity.sql

@@ -0,0 +1,5 @@
+-- 3VL TEST (Standard Identity Loss)
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} = r2.{{ join_key_a }};

sql_benchmarks/scripts/sql/null_sentinel/duckdb/2VL_identity.sql

@@ -0,0 +1,14 @@
+-- 1. Matches for Non-Nulls (Uses Hash Join)
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} = r2.{{ join_key_a }}
+
+UNION ALL
+
+-- 2. Matches for Nulls (Identity)
+-- This is just a cartesian of nulls, but isolated so it doesn't kill the Hash Join
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} IS NULL AND r2.{{ join_key_a }} IS NULL;

sql_benchmarks/scripts/sql/null_sentinel/duckdb/3VL_identity.sql

@@ -0,0 +1,5 @@
+-- 3VL TEST (Standard Identity Loss)
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} = r2.{{ join_key_a }};

sql_benchmarks/scripts/sql/null_sentinel/duckdb/sentinel_optimization.sql

@@ -0,0 +1,16 @@
+-- Benchmarks the cost of handling NULLs as a concrete value ("Identity")
+-- vs letting the database skip them (Standard 3VL).
+DROP TABLE IF EXISTS {{ r_table }}_sentinel;
+
+CREATE TABLE {{ r_table }}_sentinel AS 
+SELECT 
+    COALESCE({{ join_key_a }}, -1) AS {{ join_key_a }}
+FROM {{ r_table }};
+
+ANALYZE {{ r_table }}_sentinel;
+
+SELECT count(*)
+FROM {{ r_table }}_sentinel r1
+JOIN {{ r_table }}_sentinel r2 
+  ON r1.{{ join_key_a }} = r2.{{ join_key_a }};
+

sql_benchmarks/scripts/sql/null_sentinel/postgres/2VL_identity.sql

@@ -0,0 +1,14 @@
+-- 1. Matches for Non-Nulls (Uses Hash Join)
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} = r2.{{ join_key_a }}
+
+UNION ALL
+
+-- 2. Matches for Nulls (Identity)
+-- This is just a cartesian of nulls, but isolated so it doesn't kill the Hash Join
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} IS NULL AND r2.{{ join_key_a }} IS NULL;

sql_benchmarks/scripts/sql/null_sentinel/postgres/3VL_identity.sql

@@ -0,0 +1,5 @@
+-- 3VL TEST (Standard Identity Loss)
+SELECT count(*) 
+FROM {{ r_table }} r1 
+JOIN {{ r_table }} r2 
+    ON r1.{{ join_key_a }} = r2.{{ join_key_a }};

sql_benchmarks/scripts/sql/null_sentinel/postgres/sentinel_optimization.sql

@@ -0,0 +1,21 @@
+-- Benchmarks the cost of handling NULLs as a concrete value ("Identity")
+-- vs letting the database skip them (Standard 3VL).
+-- [PREP_START]
+DROP TABLE IF EXISTS {{ r_table }}_sentinel;
+
+-- 1. Physical Materialization (The "Baking" Phase)
+CREATE UNLOGGED TABLE {{ r_table }}_sentinel AS 
+SELECT 
+    COALESCE({{ join_key_a }}, -1) AS {{ join_key_a }}
+FROM {{ r_table }};
+
+-- 2. Statistic Update (The "Notification" Phase)
+ANALYZE {{ r_table }}_sentinel;
+-- [PREP_END]
+
+-- 3. The Benchmark 
+SELECT count(*)
+FROM {{ r_table }}_sentinel r1
+JOIN {{ r_table }}_sentinel r2 
+  ON r1.{{ join_key_a }} = r2.{{ join_key_a }};
+

sql_benchmarks/scripts/sql/recursion/duckdb/recursive_cte.sql

@@ -0,0 +1,26 @@
+WITH RECURSIVE
+    -- {{ hierarchy_table }} will be rendered as `hierarchy_partitionkey` (e.g., hierarchy_small)
+    descendants (id, parent_id, name, depth) AS (
+        SELECT 
+            id, 
+            parent_id, 
+            name, 
+            1 AS depth 
+        FROM {{ hierarchy_data_table }}
+        WHERE id = 1 -- Start at a known root/branch node
+
+        UNION ALL
+
+        SELECT 
+            t.id, 
+            t.parent_id, 
+            t.name, 
+            d.depth + 1
+        FROM {{ hierarchy_data_table }} AS t
+        INNER JOIN descendants AS d 
+            ON t.parent_id = d.id
+)
+SELECT 
+    -- The final result is the count of all descendant nodes found
+    count(*) 
+FROM descendants;

sql_benchmarks/scripts/sql/recursion/postgres/recursive_cte.sql

@@ -0,0 +1,30 @@
+-- sql_queries/postgres/recursion_cte.sql
+-- Recursively finds all descendants (or ancestors) of a specific node.
+-- We use node ID 1 as a common starting point.
+
+WITH RECURSIVE
+    -- {{ hierarchy_table }} will be rendered as `hierarchy_partitionkey`
+    descendants (id, parent_id, name, depth) AS (
+        SELECT 
+            id, 
+            parent_id, 
+            name, 
+            1 AS depth 
+        FROM {{ hierarchy_data_table }} AS t
+        WHERE id = 1 -- Start at a known root/branch node
+
+        UNION ALL
+
+        SELECT 
+            t.id, 
+            t.parent_id, 
+            t.name, 
+            d.depth + 1
+        FROM {{ hierarchy_data_table }} AS t
+        INNER JOIN descendants AS d 
+            ON t.parent_id = d.id
+)
+SELECT 
+    -- The final result is the count of all descendant nodes found
+    count(*) 
+FROM descendants;

sql_benchmarks/scripts/sql/recursive_graph/duckdb/q_bounded_3hop.sql

@@ -0,0 +1,17 @@
+-- Bounded variable-depth: all companies reachable from node 1 in up to 3 hops.
+-- Recursive CTE with depth guard. Intermediate result set materialised at each
+-- step — this is where OOM occurs on hub-heavy Zipf graphs.
+WITH RECURSIVE reachable(company_id, depth) AS (
+    SELECT to_id AS company_id, 1 AS depth
+    FROM {{ supplies_table }}
+    WHERE from_id = 1
+
+    UNION
+
+    SELECT s.to_id, r.depth + 1
+    FROM reachable r
+    JOIN {{ supplies_table }} s ON s.from_id = r.company_id
+    WHERE r.depth < 3
+)
+SELECT COUNT(DISTINCT company_id) AS reachable_count
+FROM reachable;

sql_benchmarks/scripts/sql/recursive_graph/duckdb/q_fixed_2hop.sql

@@ -0,0 +1,6 @@
+-- Fixed 2-hop: companies reachable from node 1 in exactly 2 supply steps.
+-- Baseline — DuckDB should win comfortably. Two plain JOINs on integer FKs.
+SELECT DISTINCT s2.to_id AS company_id
+FROM {{ supplies_table }} s1
+JOIN {{ supplies_table }} s2 ON s1.to_id = s2.from_id
+WHERE s1.from_id = 1;

sql_benchmarks/scripts/sql/recursive_graph/duckdb/q_transitive_closure.sql

@@ -0,0 +1,17 @@
+-- Full transitive closure from node 1: every company that directly or
+-- indirectly depends on node 1 in the supply chain.
+-- No depth limit — the CTE runs until no new nodes are discovered.
+-- This is the query most likely to OOM on a Zipf hub at medium scale.
+WITH RECURSIVE closure(company_id) AS (
+    SELECT to_id AS company_id
+    FROM {{ supplies_table }}
+    WHERE from_id = 1
+
+    UNION
+
+    SELECT s.to_id
+    FROM closure c
+    JOIN {{ supplies_table }} s ON s.from_id = c.company_id
+)
+SELECT COUNT(DISTINCT company_id) AS total_reachable
+FROM closure;

sql_benchmarks/scripts/sql/recursive_graph/typedb/q_bounded_3hop.sql

@@ -0,0 +1,6 @@
+match
+  $root isa {{ company_table }}, has id 1;
+  (seller_role: $root, buyer_role: $hop1) isa {{ supplies_table }};
+  (seller_role: $hop1, buyer_role: $hop2) isa {{ supplies_table }};
+  (seller_role: $hop2, buyer_role: $leaf) isa {{ supplies_table }};
+select $hop1, $hop2, $leaf;

sql_benchmarks/scripts/sql/recursive_graph/typedb/q_fixed_2hop.sql

@@ -0,0 +1,5 @@
+match
+  (seller_role: $a, buyer_role: $b) isa {{ supplies_table }};
+  (seller_role: $b, buyer_role: $c) isa {{ supplies_table }};
+  $a isa {{ company_table }}, has id 1;
+select $c;

sql_benchmarks/scripts/sql/recursive_graph/typedb/q_transitive_closure.sql

@@ -0,0 +1,7 @@
+# Full transitive closure from node 1 using a TypeDB 3.x recursive stream function.
+# The 'reachable' function is defined in the schema and evaluated lazily with tabling
+# (automatic cycle detection / fixed-point termination). No explicit loop needed.
+match
+  $root isa {{ company_table }}, has id 1;
+  let $reachable in reachable($root);
+select $reachable;

sql_benchmarks/scripts/sql/security/acid_resilience/duckdb/test.sql

@@ -0,0 +1 @@
+SELECT COUNT(*) FROM heartbeat;

sql_benchmarks/scripts/sql/selectivity/duckdb/q_0_1_percent.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'sel_0_1';

sql_benchmarks/scripts/sql/selectivity/duckdb/q_10_percent.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'sel_10';

sql_benchmarks/scripts/sql/selectivity/duckdb/q_1_percent.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'sel_1';

sql_benchmarks/scripts/sql/selectivity/duckdb/q_20_percent.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'sel_20';

sql_benchmarks/scripts/sql/selectivity/duckdb/q_5_percent.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'sel_5';

sql_benchmarks/scripts/sql/selectivity/duckdb/q_filler.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'filler';

sql_benchmarks/scripts/sql/selectivity/postgres/q_0_1_percent.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'sel_0_1';

sql_benchmarks/scripts/sql/selectivity/postgres/q_10_percent.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'sel_10';

sql_benchmarks/scripts/sql/selectivity/postgres/q_1_percent.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'sel_1';

sql_benchmarks/scripts/sql/selectivity/postgres/q_20_percent.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'sel_20';

sql_benchmarks/scripts/sql/selectivity/postgres/q_5_percent.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'sel_5';

sql_benchmarks/scripts/sql/selectivity/postgres/q_filler.sql

@@ -0,0 +1 @@
+SELECT count(*) FROM {{ skewed_data_table }} WHERE selectivity_code = 'filler';

sql_benchmarks/scripts/sql/selectivity/typedb/q_0_1_percent.sql

@@ -0,0 +1,4 @@
+match
+  $x isa {{ skewed_data_table }},
+    has selectivity_code "sel_0_1";
+select $x;

sql_benchmarks/scripts/sql/selectivity/typedb/q_10_percent.sql

@@ -0,0 +1,4 @@
+match
+  $x isa {{ skewed_data_table }},
+    has selectivity_code "sel_10";
+select $x;

sql_benchmarks/scripts/sql/selectivity/typedb/q_1_percent.sql

@@ -0,0 +1,4 @@
+match
+  $x isa {{ skewed_data_table }},
+    has selectivity_code "sel_1";
+select $x;

sql_benchmarks/scripts/sql/selectivity/typedb/q_20_percent.sql

@@ -0,0 +1,4 @@
+match
+  $x isa {{ skewed_data_table }},
+    has selectivity_code "sel_20";
+select $x;

sql_benchmarks/scripts/sql/selectivity/typedb/q_5_percent.sql

@@ -0,0 +1,4 @@
+match
+  $x isa {{ skewed_data_table }},
+    has selectivity_code "sel_5";
+select $x;

sql_benchmarks/scripts/sql/selectivity/typedb/q_filler.sql

@@ -0,0 +1,4 @@
+match
+  $x isa {{ skewed_data_table }},
+    has selectivity_code "filler";
+select $x;

sql_benchmarks/scripts/sql/sort_spill/duckdb/sort_full.sql

@@ -0,0 +1,25 @@
+-- Sort Spill: Full sort (no LIMIT) on wide rows (DuckDB control).
+-- DuckDB uses vectorized execution and adaptive memory management.
+-- No work_mem equivalent — spill is handled transparently.
+-- Compare against postgres/sort_full.sql: without top-N optimization,
+-- the full architectural cost of row-at-a-time vs vectorized sort is exposed.
+
+SELECT
+    id,
+    region,
+    category,
+    department,
+    sub_category,
+    ROUND(price, 4)                              AS price,
+    ROUND(cost, 4)                               AS cost,
+    ROUND(margin, 4)                             AS margin,
+    quantity,
+    discount,
+    ROUND(price * quantity * (1.0 - discount), 4) AS net_revenue
+FROM {{ sort_data_table }}
+ORDER BY
+    region ASC,
+    category ASC,
+    department ASC,
+    net_revenue DESC,
+    quantity DESC;

sql_benchmarks/scripts/sql/sort_spill/duckdb/sort_wide_rows.sql

@@ -0,0 +1,25 @@
+-- Sort Spill: Multi-column sort on wide rows (DuckDB control).
+-- DuckDB manages memory adaptively — no work_mem equivalent.
+-- This is the control arm: same query, no spill constraint.
+-- Compare against postgres/sort_wide_rows.sql to isolate the spill cost.
+
+SELECT
+    id,
+    region,
+    category,
+    department,
+    sub_category,
+    ROUND(price, 4)                              AS price,
+    ROUND(cost, 4)                               AS cost,
+    ROUND(margin, 4)                             AS margin,
+    quantity,
+    discount,
+    ROUND(price * quantity * (1.0 - discount), 4) AS net_revenue
+FROM {{ sort_data_table }}
+ORDER BY
+    region ASC,
+    category ASC,
+    department ASC,
+    net_revenue DESC,
+    quantity DESC
+LIMIT 1000;

sql_benchmarks/scripts/sql/sort_spill/postgres/sort_full.sql

@@ -0,0 +1,25 @@
+-- Sort Spill: Full sort (no LIMIT) on wide rows.
+-- Without LIMIT, Postgres cannot use the top-N heap sort optimization.
+-- The entire result set must be sorted in memory or spilled to disk.
+-- At tight work_mem (4MB), spill will occur at low row counts.
+-- This is where the cliff actually lives.
+
+SELECT
+    id,
+    region,
+    category,
+    department,
+    sub_category,
+    ROUND(CAST(price AS NUMERIC), 4)        AS price,
+    ROUND(CAST(cost AS NUMERIC), 4)         AS cost,
+    ROUND(CAST(margin AS NUMERIC), 4)       AS margin,
+    quantity,
+    discount,
+    ROUND(CAST(price * quantity * (1.0 - discount) AS NUMERIC), 4) AS net_revenue
+FROM {{ sort_data_table }}
+ORDER BY
+    region ASC,
+    category ASC,
+    department ASC,
+    net_revenue DESC,
+    quantity DESC;