https://ivanluminaria.com/it/tags/explain/Recent content in Explain on Ivan LuminariaHugoitTue, 28 Oct 2025 08:03:00 +0100https://ivanluminaria.com/it/posts/postgresql/explain-analyze-postgresql/Tue, 28 Oct 2025 08:03:00 +0100https://ivanluminaria.com/it/posts/postgresql/explain-analyze-postgresql/<p>L&rsquo;altro giorno un collega mi manda uno screenshot su Teams. Una query che gira su una tabella da 2 milioni di righe, 45 secondi di esecuzione. Mi scrive:</p> <blockquote> <p>&ldquo;Ho fatto EXPLAIN ANALYZE, ma non capisco cosa c&rsquo;è che non va. Il piano sembra corretto.&rdquo;</p> </blockquote> <p>Spoiler: il piano non era affatto corretto. L&rsquo;optimizer aveva scelto un <span class="glossary-tip" tabindex="0" data-glossary-desc="Nested Loop Join — strategia di join che scansiona la tabella interna per ogni riga della tabella esterna, ideale per dataset piccoli con indice." data-glossary-url="https://ivanluminaria.com/it/glossary/nested-loop/" data-glossary-more="Leggi di più →">nested loop</span> join dove serviva un <span class="glossary-tip" tabindex="0" data-glossary-desc="Hash Join — strategia di join ottimizzata per grandi volumi di dati, basata su una hash table costruita in memoria." data-glossary-url="https://ivanluminaria.com/it/glossary/hash-join/" data-glossary-more="Leggi di più →">hash join</span> , e la ragione era banale — statistiche non aggiornate. Ma per arrivarci ho dovuto leggere il piano riga per riga, e lì mi sono reso conto che la maggior parte dei DBA che conosco usa EXPLAIN ANALYZE come un oracolo binario: se il tempo è alto, la query è lenta. Fine dell&rsquo;analisi.</p>