<?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>Cost-Model on Kent Yao</title>
    <link>https://yaooqinn.github.io/tags/cost-model/</link>
    <description>Recent content in Cost-Model 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/tags/cost-model/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>
  </channel>
</rss>
