<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Benchmarks on lqo.net</title>
    <link>https://lqo.net/tags/benchmarks/</link>
    <description>Recent content in Benchmarks on lqo.net</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 19 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://lqo.net/tags/benchmarks/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>LQO Finds Faster PostgreSQL Plans for 35 of 94 Join Order Benchmark Query Shapes</title>
      <link>https://lqo.net/lqo-finds-faster-postgresql-plans-for-35-of-94-join-order-benchmark-query-shapes/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://lqo.net/lqo-finds-faster-postgresql-plans-for-35-of-94-join-order-benchmark-query-shapes/</guid>
      <description>&lt;p&gt;The Join Order Benchmark is where query optimizers go to be embarrassed. It&amp;rsquo;s 113 queries over the IMDB movie database, real data with all its skew and correlated columns, and it was built to show how far a planner&amp;rsquo;s row estimates can drift from the truth. If a tool claims to find better plans, this is the first place anyone should look.&lt;/p&gt;&#xA;&lt;p&gt;So LQO 0.1.0 ran it, start to finish, on a GitHub runner: 4 cores, 15 GB of memory, PostgreSQL 16 with 5 GB of shared buffers. The 113 queries fold into 94 query shapes, because some JOB variants differ only in their constants. Each shape ran under the default plan and under LQO&amp;rsquo;s 13 standard hints, with a warm-up run and three timed runs per plan. The whole thing took 75 minutes.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
