
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Sun, 09 Aug 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/query-engine/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/database/2026-08-09-volcano-model-and-vectorized-execution.en</guid>
    <title>The 300x Is Not a Number You Get by Tuning PostgreSQL — The Volcano Model and Vectorized Execution</title>
    <link>https://www.youngju.dev/blog/database/2026-08-09-volcano-model-and-vectorized-execution.en</link>
    <description>A precise dissection of the 300x published alongside the pgrust 0.2 release. That figure did not come from changing a PostgreSQL setting; it is a ClickBench measurement of a database newly implemented in Rust, while the separate SUM query experiment the author presents shows 9.6x, from 1.3 seconds on the volcano model down to 135 milliseconds with SIMD. We follow at the code level what batching, operator fusion, and SIMD each remove, and separate the limits the author states about the work from the alternatives you can actually use on real PostgreSQL today.</description>
    <pubDate>Sun, 09 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>postgresql</category><category>database</category><category>performance</category><category>query-engine</category><category>simd</category><category>olap</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/database/2026-08-09-volcano-model-and-vectorized-execution.ja</guid>
    <title>300倍はPostgreSQLをチューニングして出た数字ではない — 火山モデルとベクトル化実行</title>
    <link>https://www.youngju.dev/blog/database/2026-08-09-volcano-model-and-vectorized-execution.ja</link>
    <description>pgrust 0.2のリリースとともに公開された300倍という数字を正確に解剖します。この数値はPostgreSQLの設定を変えて出たものではなく、Rustで新しく実装したデータベースをClickBenchで測定した結果であり、著者本人が別に提示したSUMクエリの実験は火山モデルの1.3秒からSIMDの135ミリ秒まで9.6倍を示します。バッチ、演算子融合、SIMDがそれぞれ何を取り除くのかをコードのレベルで追い、著者が自ら明かした限界と、実際のPostgreSQLで今日すぐ使える代案とを区別します。</description>
    <pubDate>Sun, 09 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>postgresql</category><category>database</category><category>performance</category><category>query-engine</category><category>simd</category><category>olap</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/database/2026-08-09-volcano-model-and-vectorized-execution</guid>
    <title>300배는 PostgreSQL을 튜닝해서 나온 숫자가 아니다 — 화산 모델과 벡터화 실행</title>
    <link>https://www.youngju.dev/blog/database/2026-08-09-volcano-model-and-vectorized-execution</link>
    <description>pgrust 0.2 릴리스와 함께 공개된 300배라는 숫자를 정확히 해부합니다. 이 수치는 PostgreSQL 설정을 바꿔서 나온 것이 아니라 Rust로 새로 구현한 데이터베이스를 ClickBench에서 측정한 결과이며, 저자 본인이 별도로 제시한 SUM 쿼리 실험은 화산 모델 1.3초에서 SIMD 135밀리초까지 9.6배를 보여 줍니다. 배치, 연산자 융합, SIMD가 각각 무엇을 제거하는지 코드 수준에서 따라가고, 저자가 스스로 밝힌 한계와 실제 PostgreSQL에서 오늘 당장 쓸 수 있는 대안을 구분합니다.</description>
    <pubDate>Sun, 09 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>postgresql</category><category>database</category><category>performance</category><category>query-engine</category><category>simd</category><category>olap</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/database/2026-08-09-volcano-model-and-vectorized-execution.zh</guid>
    <title>300 倍不是调 PostgreSQL 调出来的数字 —— 火山模型与向量化执行</title>
    <link>https://www.youngju.dev/blog/database/2026-08-09-volcano-model-and-vectorized-execution.zh</link>
    <description>精确解剖随 pgrust 0.2 发布一起公开的那个 300 倍。这个数字不是改 PostgreSQL 配置得来的，而是把一个用 Rust 重写的数据库放到 ClickBench 上测出来的结果；而作者另外给出的 SUM 查询实验，是从火山模型的 1.3 秒到 SIMD 的 135 毫秒，也就是 9.6 倍。我们在代码层面跟一遍批处理、算子融合、SIMD 各自消掉了什么，并把作者自己讲明的局限，和你今天就能在真实 PostgreSQL 上用的替代方案分开来看。</description>
    <pubDate>Sun, 09 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>postgresql</category><category>database</category><category>performance</category><category>query-engine</category><category>simd</category><category>olap</category>
  </item>

    </channel>
  </rss>
