https://ivanluminaria.com/en/tags/explain/Recent content in Explain on Ivan LuminariaHugoenTue, 28 Oct 2025 08:03:00 +0100https://ivanluminaria.com/en/posts/postgresql/explain-analyze-postgresql/Tue, 28 Oct 2025 08:03:00 +0100https://ivanluminaria.com/en/posts/postgresql/explain-analyze-postgresql/<p>The other day a colleague sends me a screenshot on Teams. A query running on a 2-million-row table, 45 seconds execution time. He writes:</p> <blockquote> <p>&ldquo;I ran EXPLAIN ANALYZE, but I can&rsquo;t figure out what&rsquo;s wrong. The plan looks fine.&rdquo;</p> </blockquote> <p>Spoiler: the plan was anything but fine. The optimizer had chosen a <span class="glossary-tip" tabindex="0" data-glossary-desc="Nested Loop Join — the join strategy that scans the inner table for each row of the outer table, ideal for small datasets with an index." data-glossary-url="https://ivanluminaria.com/en/glossary/nested-loop/" data-glossary-more="Read more →">nested loop</span> join where a <span class="glossary-tip" tabindex="0" data-glossary-desc="Hash Join — a join strategy optimized for large data volumes, based on a hash table built in memory." data-glossary-url="https://ivanluminaria.com/en/glossary/hash-join/" data-glossary-more="Read more →">hash join</span> was needed, and the reason was trivial — stale statistics. But to get there I had to read the plan line by line, and that&rsquo;s when I realized that most DBAs I know use EXPLAIN ANALYZE as a binary oracle: if the time is high, the query is slow. End of analysis.</p>