<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>LQO on SoftDevStudio.com</title>
    <link>https://softdevstudio.com/tags/lqo/</link>
    <description>Recent content in LQO 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/lqo/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>LQO Adds a Proxy That Learns Faster PostgreSQL Plans From Live Traffic</title>
      <link>https://softdevstudio.com/lqo-adds-a-proxy-that-learns-faster-postgresql-plans-from-live-traffic/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://softdevstudio.com/lqo-adds-a-proxy-that-learns-faster-postgresql-plans-from-live-traffic/</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.2.0 adds &lt;code&gt;lqo serve&lt;/code&gt;. Instead of reading a log, LQO now sits between the application and PostgreSQL as a proxy, passes every message through unchanged, and times every query by shape. With a replica to work on, it tries the slow shapes there under PostgreSQL&amp;rsquo;s planner settings, three at a time, picked by Thompson sampling, and proves a setting only under the same strict rule as &lt;code&gt;lqo advise&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;This version only watches and reports, on a status page and in its state file. &lt;a href=&#34;https://lqo.net/lqo-now-runs-as-a-postgresql-proxy-and-learns-faster-plans-from-live-traffic/&#34;&gt;In the test run&lt;/a&gt;, it proved &amp;ldquo;no nested loop&amp;rdquo; for the demo&amp;rsquo;s trap query after about five minutes of learning, around 22% faster on the replica. Active mode, which applies proven settings to live queries and takes one back if it runs slower, is next.&lt;/p&gt;</description>
    </item>
    <item>
      <title>LQO Corrects PostgreSQL Row Estimates Where One Planner Switch Is Not Enough</title>
      <link>https://softdevstudio.com/lqo-corrects-postgresql-row-estimates-where-one-planner-switch-is-not-enough/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://softdevstudio.com/lqo-corrects-postgresql-row-estimates-where-one-planner-switch-is-not-enough/</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.5.0 adds row-count hints for servers with the pg_hint_plan extension. LQO already times each query&amp;rsquo;s default plan with &lt;code&gt;EXPLAIN ANALYZE&lt;/code&gt;, so it knows how many rows each join really produced. Where the planner&amp;rsquo;s estimate was more than 2 times off, it writes a pg_hint_plan hint that corrects it and lets PostgreSQL plan again. That&amp;rsquo;s for queries that need different joins in different places, where switching one method off for the whole query does as much harm as good.&lt;/p&gt;</description>
    </item>
    <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 Launches, Finding the PostgreSQL Queries a Planner Setting Makes Faster</title>
      <link>https://softdevstudio.com/lqo-launches-finding-the-postgresql-queries-a-planner-setting-makes-faster/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://softdevstudio.com/lqo-launches-finding-the-postgresql-queries-a-planner-setting-makes-faster/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://lqo.net/what-is-a-learned-query-optimizer-why-postgresql-picks-slow-plans-and-how-to-steer-it/&#34;&gt;LQO&lt;/a&gt;, the studio&amp;rsquo;s eighteenth project, is a learned query optimizer for PostgreSQL that steers the planner instead of replacing it. PostgreSQL picks each plan from row counts it guesses, and when two columns are related the guess can be off by thousands. LQO reads a server log or a file of queries, then runs each kind of query under the default plan and under 13 of PostgreSQL&amp;rsquo;s own planner settings, on a replica or a copy. It reports the settings that make a query clearly faster, with the &lt;code&gt;SET LOCAL&lt;/code&gt; lines to use. Version 0.1.0 &lt;a href=&#34;https://lqo.net/first-lqo-release-finds-the-postgresql-queries-a-planner-setting-makes-faster/&#34;&gt;came out on 19 October&lt;/a&gt; as one Go binary with no dependencies, its own PostgreSQL client included, with &lt;a href=&#34;https://github.com/learned-query-optimizer/lqo/releases/latest&#34;&gt;binaries&lt;/a&gt; for Linux, macOS and Windows. It&amp;rsquo;s open source under Apache 2.0.&lt;/p&gt;</description>
    </item>
    <item>
      <title>LQO Learns From Similar PostgreSQL Queries and Proves New Ones With Half the Replica Time</title>
      <link>https://softdevstudio.com/lqo-learns-from-similar-postgresql-queries-and-proves-new-ones-with-half-the-replica-time/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://softdevstudio.com/lqo-learns-from-similar-postgresql-queries-and-proves-new-ones-with-half-the-replica-time/</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.4.0 lets &lt;code&gt;lqo serve&lt;/code&gt; learn across queries. Queries that read the same tables are relatives, and a new one starts from what its relatives showed. Hints that won for them are tried first. If a relative already proved a hint, the new query tries that hint alone, one plan per round instead of three, for as long as it keeps winning outright. Proof still happens on the new query&amp;rsquo;s own texts, by the same rule.&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>
    <item>
      <title>LQO Starts Applying Proven Planner Settings to Live PostgreSQL Queries</title>
      <link>https://softdevstudio.com/lqo-starts-applying-proven-planner-settings-to-live-postgresql-queries/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://softdevstudio.com/lqo-starts-applying-proven-planner-settings-to-live-postgresql-queries/</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.3.0 adds active mode to &lt;code&gt;lqo serve&lt;/code&gt;. Until now the proxy only learned and reported. With &lt;code&gt;--mode active&lt;/code&gt; it applies each setting it has proven, such as nested loops switched off, to the live calls of that query shape. The setting goes in with &lt;code&gt;SET LOCAL&lt;/code&gt; in the same round trip, so it ends with that statement&amp;rsquo;s transaction, and only for a statement that is its own transaction. The application sees the same replies it would without LQO.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
