<?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 SoftDevStudio.com</title>
    <link>https://softdevstudio.com/tags/benchmarks/</link>
    <description>Recent content in Benchmarks on SoftDevStudio.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 19 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://softdevstudio.com/tags/benchmarks/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>LQO Finds Faster Plans for 35 of 94 Join Order Benchmark Query Shapes</title>
      <link>https://softdevstudio.com/lqo-finds-faster-plans-for-35-of-94-join-order-benchmark-query-shapes/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://softdevstudio.com/lqo-finds-faster-plans-for-35-of-94-join-order-benchmark-query-shapes/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://softdevstudio.com/lqo-launches-finding-the-postgresql-queries-a-planner-setting-makes-faster/&#34;&gt;LQO&lt;/a&gt; 0.1.0 has now run the Join Order Benchmark, the standard test for query optimizers: 113 queries over the IMDB movie database, which fold into 94 query shapes. It ran on a 4-core GitHub runner with PostgreSQL 16, each shape tried under the default plan and LQO&amp;rsquo;s 13 planner settings.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://lqo.net/lqo-finds-faster-postgresql-plans-for-35-of-94-join-order-benchmark-query-shapes/&#34;&gt;The results&lt;/a&gt;: 35 shapes got a suggestion and 59 stayed on the default plan. Where LQO suggested something, it saved 21% to 98%, median 48%, and one pass over every tested query went from 172.6 seconds to 77.6. One query, JOB 26c, did most of that, 59.2 seconds down to 1.2 with parallel workers off; without it the pass still drops by a third. No single setting won: switching off nested loops, hash joins, index scans, memoize and parallel workers each fixed different queries.&lt;/p&gt;</description>
    </item>
    <item>
      <title>LQO Row Count Hints Speed Up 9 Join Order Benchmark Queries No Planner Switch Could Fix</title>
      <link>https://softdevstudio.com/lqo-row-count-hints-speed-up-9-join-order-benchmark-queries-no-planner-switch-could-fix/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://softdevstudio.com/lqo-row-count-hints-speed-up-9-join-order-benchmark-queries-no-planner-switch-could-fix/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://softdevstudio.com/lqo-launches-finding-the-postgresql-queries-a-planner-setting-makes-faster/&#34;&gt;LQO&lt;/a&gt; ran the Join Order Benchmark again, this time with pg_hint_plan, so it could try its row-count hints next to the planner switches. Inside that one run, the switches alone would have sped up 34 of the 94 query shapes, one pass from 133.1 to 78.0 seconds. With row counts as well, 43 shapes and 69.8 seconds.&lt;/p&gt;&#xA;&lt;p&gt;Row counts won 13 shapes, and 9 of them were ones no switch could fix, such as JOB 18a, 2,338 ms down to 381 ms. &lt;a href=&#34;https://lqo.net/row-count-hints-speed-up-9-join-order-benchmark-queries-no-postgresql-planner-switch-could-fix/&#34;&gt;The write-up&lt;/a&gt; explains why this run isn&amp;rsquo;t compared with the first one, which ran on a different machine.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
