<?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>Performance on pgAssistant Blog</title><link>https://beh74.github.io/pgassistant-blog/tags/performance/</link><description>Recent content in Performance on pgAssistant Blog</description><generator>Hugo -- 0.147.0</generator><language>en-us</language><lastBuildDate>Tue, 12 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://beh74.github.io/pgassistant-blog/tags/performance/index.xml" rel="self" type="application/rss+xml"/><item><title>PostgreSQL: Which Queries Should You Optimize First?</title><link>https://beh74.github.io/pgassistant-blog/post/ranking/</link><pubDate>Tue, 12 May 2026 00:00:00 +0000</pubDate><guid>https://beh74.github.io/pgassistant-blog/post/ranking/</guid><description>&lt;p>&lt;img alt="Ranking" loading="lazy" src="https://beh74.github.io/pgassistant-blog/images/ranking.png">&lt;/p>
&lt;p>When investigating PostgreSQL performance, the usual starting point is &lt;code>pg_stat_statements&lt;/code>. From there, many teams sort queries by &lt;code>mean_exec_time&lt;/code> or &lt;code>total_exec_time&lt;/code> and start optimizing the first rows in the list.&lt;/p>
&lt;p>That approach is simple, but it often leads to the wrong priorities.&lt;/p>
&lt;p>A query that takes five seconds but runs twice a day is not necessarily more important than a query that takes five milliseconds and runs millions of times. Conversely, a query with a high total execution time may simply be a normal core workload query, not necessarily the best optimization target.&lt;/p></description></item><item><title>Designing the Right PostgreSQL Index Using Query Plans and Statistics</title><link>https://beh74.github.io/pgassistant-blog/post/query_advisor/</link><pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate><guid>https://beh74.github.io/pgassistant-blog/post/query_advisor/</guid><description>&lt;p>&lt;img alt="Index Advisor" loading="lazy" src="https://beh74.github.io/pgassistant-blog/images/index_advisor_cover.png">&lt;/p>
&lt;p>PostgreSQL index design is often misunderstood.&lt;/p>
&lt;p>Many developers think that creating a good index simply means:&lt;/p>
&lt;blockquote>
&lt;p>“Create an index containing the columns from the WHERE clause.”&lt;/p>&lt;/blockquote>
&lt;p>In reality, efficient index design is far more nuanced.&lt;/p>
&lt;p>The order of columns inside a composite index matters enormously, and the best choice depends on:&lt;/p>
&lt;ul>
&lt;li>Predicate types (&lt;code>=&lt;/code>, &lt;code>&amp;gt;=&lt;/code>, &lt;code>BETWEEN&lt;/code>, &lt;code>LIKE&lt;/code>, etc.)&lt;/li>
&lt;li>Column selectivity&lt;/li>
&lt;li>Table size&lt;/li>
&lt;li>PostgreSQL planner statistics&lt;/li>
&lt;li>Actual execution plans&lt;/li>
&lt;/ul>
&lt;p>This article explains the core principles behind efficient PostgreSQL index design before showing how pgAssistant automates this process using execution plans and database statistics.&lt;/p></description></item><item><title>Detecting PostgreSQL optimization issues with deterministic analysis</title><link>https://beh74.github.io/pgassistant-blog/post/global_advisor/</link><pubDate>Sun, 10 May 2026 00:00:00 +0000</pubDate><guid>https://beh74.github.io/pgassistant-blog/post/global_advisor/</guid><description>&lt;h1 id="detecting-postgresql-optimization-issues-with-deterministic-analysis">Detecting PostgreSQL optimization issues with deterministic analysis&lt;/h1>
&lt;p>&lt;img alt="Global Advisor" loading="lazy" src="https://beh74.github.io/pgassistant-blog/images/global-advisor-1.png">&lt;/p>
&lt;p>For years, I kept seeing the same PostgreSQL problems in production:&lt;/p>
&lt;ul>
&lt;li>missing foreign key indexes&lt;/li>
&lt;li>stale statistics&lt;/li>
&lt;li>unused indexes&lt;/li>
&lt;li>datatype mismatches&lt;/li>
&lt;li>sequences approaching exhaustion&lt;/li>
&lt;li>postgres configuration&lt;/li>
&lt;/ul>
&lt;p>Most of these issues are not difficult to detect.&lt;/p>
&lt;p>They already exist inside PostgreSQL catalogs, statistics, &amp;hellip;&lt;/p>
&lt;p>The difficult part is usually connecting the signals together and understanding their operational impact.&lt;/p>
&lt;p>For the past months, I have been working on a deterministic PostgreSQL analysis approach inside pgAssistant 2.8.&lt;/p></description></item></channel></rss>