<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Kent Yao</title>
    <link>https://yaooqinn.github.io/</link>
    <description>Recent content on Kent Yao</description>
    <generator>Hugo -- 0.157.0</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 31 May 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://yaooqinn.github.io/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>LLMs as Cardinality Estimators: Accurate, But Only If You Don&#39;t Call Them Every Time</title>
      <link>https://yaooqinn.github.io/posts/query-engines/llm-cardinality-estimator/</link>
      <pubDate>Sun, 31 May 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/query-engines/llm-cardinality-estimator/</guid>
      <description>Cardinality estimation is the heart of the optimizer. A team from Peking University and ByteDance fine-tunes Llama-3 8B to do CardEst, and on workloads like IMDB and STATS the 99th-percentile Q-error drops by up to 74.1% versus the strongest baseline (PRICE) — the accuracy win is real. But end-to-end, it backfires: on JOB-light and ErgastF1 the LLM&amp;rsquo;s more accurate plans are dragged down by its own inference latency, with total time exceeding even the strongest baseline PRICE. The real engineering contribution isn&amp;rsquo;t the model — it&amp;rsquo;s the gate that uses the optimizer&amp;rsquo;s own cost model as a bouncer: call the LLM only for high-cost sub-queries, leave the rest to the old methods.</description>
    </item>
    <item>
      <title>When the Index Tuner&#39;s Cost Model Lies: Where LLMs See What DTA Can&#39;t</title>
      <link>https://yaooqinn.github.io/posts/query-engines/llm-index-tuning-vs-dta/</link>
      <pubDate>Sat, 30 May 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/query-engines/llm-index-tuning-vs-dta/</guid>
      <description>A Microsoft team evaluates LLM-driven index tuning on real enterprise customer workloads. On query 22 of Real-R, the SOTA commercial tuner DTA recommends indexes that cause a near-10x regression; on the same query, GPT-5 cuts execution time from 10 seconds to 4. The LLM wins precisely where the what-if cost model is wrong. But that intuition is high-variance, can&amp;rsquo;t be bolted into the existing architecture, and can&amp;rsquo;t be validated cheaply — it&amp;rsquo;s not a replacement for DTA today, it&amp;rsquo;s a source of the candidate indexes DTA can&amp;rsquo;t see.</description>
    </item>
    <item>
      <title>−46% or −2%? Rule-Based Rewriters Only Work at Home</title>
      <link>https://yaooqinn.github.io/posts/query-engines/rule-rewrite-blindspot-dsb/</link>
      <pubDate>Wed, 27 May 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/query-engines/rule-rewrite-blindspot-dsb/</guid>
      <description>On TPC-H 10GB, a state-of-the-art learned rewriter cuts mean execution time from 69.84s to 37.57s — a 46% win. On DSB 10GB, the same rewriter takes 32.62s to 31.93s — a 2.1% non-event. The gap isn&amp;rsquo;t query difficulty; it&amp;rsquo;s whether the benchmark is in the rewriter&amp;rsquo;s training distribution. &amp;ldquo;Rule-based systems are stable and reliable&amp;rdquo; is often a benchmark artifact, not an engineering fact.</description>
    </item>
    <item>
      <title>Anatomy of a 120-Line Prompt That Lets an LLM Rewrite Physical Plans</title>
      <link>https://yaooqinn.github.io/posts/query-engines/prompt-anatomy-for-plan-generation/</link>
      <pubDate>Wed, 27 May 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/query-engines/prompt-anatomy-for-plan-generation/</guid>
      <description>DBPlanBench gets GPT-5 to deliver a 4.78× geometric-mean speedup on DataFusion TPC-H SF10 by letting the model rewrite physical plans directly. I read its sql_optimization_prompts.py end to end — 120 lines, 30 of methodology, 90 of contract. That ratio is the most transferable thing in the paper.</description>
    </item>
    <item>
      <title>LLMs Shouldn&#39;t Replace the Query Optimizer — They Should Sit Behind It</title>
      <link>https://yaooqinn.github.io/posts/query-engines/llm-as-plan-tuner-not-optimizer/</link>
      <pubDate>Wed, 27 May 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/query-engines/llm-as-plan-tuner-not-optimizer/</guid>
      <description>Putting the LLM after the optimizer, emitting JSON patches for local plan tuning, is easier to reason about as engineering than asking it to replace the cost-based optimizer.</description>
    </item>
    <item>
      <title>Branch Flip Analysis: A White-Box Way to Find Performance Bugs, and What It Means for Spark</title>
      <link>https://yaooqinn.github.io/posts/spark/branch-flip-analysis-from-postgres-to-spark/</link>
      <pubDate>Tue, 26 May 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/branch-flip-analysis-from-postgres-to-spark/</guid>
      <description>An ETH paper finds 21 previously unknown performance bugs in PostgreSQL, MySQL, CockroachDB and MariaDB by flipping optimization branches on and off. The technique is conceptually simple, the surface in Spark is unusually inviting, and the open-source engine community already ships one of the building blocks.</description>
    </item>
    <item>
      <title>Just Asking an LLM to Rewrite SQL Does Almost Nothing</title>
      <link>https://yaooqinn.github.io/posts/query-engines/llm-only-rewrite-doesnt-work/</link>
      <pubDate>Tue, 26 May 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/query-engines/llm-only-rewrite-doesnt-work/</guid>
      <description>On TPC-H 10GB, asking GPT-4o to rewrite SQL takes mean execution time from 78.81s down to 74.92s — almost nothing. Swap in an open 14B model, feed it plans, add a reward, fine-tune once, and the same workload drops to 29.67s. Whether LLMs can help SQL rewriting is not a question about model strength; it&amp;rsquo;s a question about whether you&amp;rsquo;re willing to give the model the signals it actually needs.</description>
    </item>
    <item>
      <title>LLMs for Join Order: An Apache Spark Perspective on the Three-Tier Ladder</title>
      <link>https://yaooqinn.github.io/posts/spark/llm-for-join-order-an-apache-spark-perspective/</link>
      <pubDate>Mon, 25 May 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/llm-for-join-order-an-apache-spark-perspective/</guid>
      <description>Databricks and UPenn put an LLM agent to work as an offline join-order tuner and got P90 latency down 41% / geomean 1.288× speedup on JOB&amp;rsquo;s 113 queries — beating even perfect cardinality estimates. From the trenches of an open-source query engine, here is what that result does and does not prove.</description>
    </item>
    <item>
      <title>Deep Dive into Spark SQL Metrics (Part 5): Gluten Metrics Internals</title>
      <link>https://yaooqinn.github.io/posts/spark/sql-metrics-part5-gluten-internals/</link>
      <pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/sql-metrics-part5-gluten-internals/</guid>
      <description>Part 5 of the SQL Metrics deep dive. How Gluten maps Substrait plan nodes to Velox operators, aggregates metrics across pipelines, walks the MetricsUpdaterTree, and handles aggregation sub-phases and shuffle metrics.</description>
    </item>
    <item>
      <title>Deep Dive into Spark SQL Metrics (Part 6): Metrics In Action — TPC-DS q99 with Gluten</title>
      <link>https://yaooqinn.github.io/posts/spark/sql-metrics-part6-in-action/</link>
      <pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/sql-metrics-part6-in-action/</guid>
      <description>Part 6 of the SQL Metrics series. A real-world walkthrough of TPC-DS q99 at SF10000 with Gluten/Velox, reading every metric to understand what happened during execution.</description>
    </item>
    <item>
      <title>Deep Dive into Spark SQL Metrics (Part 1): Types, Full Reference, and What They Mean</title>
      <link>https://yaooqinn.github.io/posts/spark/understanding-sql-metrics/</link>
      <pubDate>Wed, 01 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/understanding-sql-metrics/</guid>
      <description>Part 1 of a 3-part deep dive into Apache Spark&amp;rsquo;s SQL metrics system. Covers the 5 metric types, a complete reference of 100+ metrics across all operators, and how to read the numbers in the Spark UI.</description>
    </item>
    <item>
      <title>Deep Dive into Spark SQL Metrics (Part 2): Internals and How AQE Uses Them</title>
      <link>https://yaooqinn.github.io/posts/spark/sql-metrics-part2-internals/</link>
      <pubDate>Wed, 01 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/sql-metrics-part2-internals/</guid>
      <description>Part 2 of the SQL Metrics deep dive. How metrics flow from tasks to driver, and how Adaptive Query Execution uses shuffle statistics to rewrite plans at runtime.</description>
    </item>
    <item>
      <title>Deep Dive into Spark SQL Metrics (Part 3): Extension APIs, UI, and REST API</title>
      <link>https://yaooqinn.github.io/posts/spark/sql-metrics-part3-extension-api/</link>
      <pubDate>Wed, 01 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/sql-metrics-part3-extension-api/</guid>
      <description>Part 3 of the SQL Metrics deep dive. How to extend Spark with custom metrics via the DataSource V2 API, how the UI renders them, and how to query metrics programmatically.</description>
    </item>
    <item>
      <title>Deep Dive into Spark SQL Metrics (Part 4): How Gluten Extends the Metrics System</title>
      <link>https://yaooqinn.github.io/posts/spark/sql-metrics-part4-gluten/</link>
      <pubDate>Wed, 01 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/sql-metrics-part4-gluten/</guid>
      <description>Part 4 of the SQL Metrics deep dive. How Apache Gluten bridges native Velox/ClickHouse metrics back to Spark&amp;rsquo;s SQL Metrics framework, adding 60+ metrics that vanilla Spark doesn&amp;rsquo;t have.</description>
    </item>
    <item>
      <title>Spark Declarative Pipelines: A Paradigm Shift for Data Engineering</title>
      <link>https://yaooqinn.github.io/posts/spark/spark-declarative-pipelines/</link>
      <pubDate>Sat, 28 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/spark-declarative-pipelines/</guid>
      <description>Apache Spark 4.1 introduces Spark Declarative Pipelines (SDP) — a declarative framework that lets you define what your data should look like, not how to compute it. As a Spark PMC Member, here&amp;rsquo;s my take on what this means for data engineering.</description>
    </item>
    <item>
      <title>Introducing spark-advisor: An AI-Powered Spark Performance Engineer</title>
      <link>https://yaooqinn.github.io/posts/spark/spark-advisor/</link>
      <pubDate>Fri, 20 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/spark-advisor/</guid>
      <description>spark-advisor is an agent skill that turns your AI coding assistant into a Spark performance engineer — diagnosing slow jobs, detecting skew, comparing benchmark runs, and producing actionable tuning recommendations.</description>
    </item>
    <item>
      <title>spark-history-cli: Making the Spark History Server Agent-Friendly</title>
      <link>https://yaooqinn.github.io/posts/spark/spark-history-cli/</link>
      <pubDate>Wed, 18 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/spark-history-cli/</guid>
      <description>spark-history-cli brings the Spark History Server to your terminal — an interactive REPL and one-shot CLI that covers all 20 REST API endpoints. List apps, inspect jobs, drill into stages, check SQL executions, and download event logs without ever opening a browser. It also ships as a GitHub Copilot CLI skill.</description>
    </item>
    <item>
      <title>The SQL Execution Detail Page Finally Shows You What Your Jobs Are Doing</title>
      <link>https://yaooqinn.github.io/posts/spark/sql-execution-page-modernization/</link>
      <pubDate>Sat, 14 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/sql-execution-page-modernization/</guid>
      <description>The SQL execution detail page in Spark&amp;rsquo;s Web UI used to show jobs as comma-separated IDs. Now it has a full Associated Jobs table with status, duration, stage progress, and task progress bars — so you can debug SQL queries without clicking through each job individually.</description>
    </item>
    <item>
      <title>Dark Mode Comes to the Apache Spark Web UI</title>
      <link>https://yaooqinn.github.io/posts/spark/dark-mode-spark-ui/</link>
      <pubDate>Fri, 06 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/dark-mode-spark-ui/</guid>
      <description>Apache Spark&amp;rsquo;s Web UI now supports dark mode — a long-awaited quality-of-life improvement for developers who spend hours debugging jobs. Here&amp;rsquo;s why we built it and what it means for the Spark community.</description>
    </item>
    <item>
      <title>Rethinking SQL Plan Visualization in Apache Spark</title>
      <link>https://yaooqinn.github.io/posts/spark/sql-plan-visualization/</link>
      <pubDate>Thu, 05 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/posts/spark/sql-plan-visualization/</guid>
      <description>The Spark SQL plan visualization just got a major upgrade — compact node labels, clickable metric panels, and edge row counts that make join explosions immediately visible.</description>
    </item>
    <item>
      <title>About</title>
      <link>https://yaooqinn.github.io/about/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/about/</guid>
      <description>About Kent Yao</description>
    </item>
    <item>
      <title>Projects</title>
      <link>https://yaooqinn.github.io/projects/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://yaooqinn.github.io/projects/</guid>
      <description>Open source projects</description>
    </item>
  </channel>
</rss>
