https://ivanluminaria.com/ro/tags/explain/Recent content in Explain on Ivan LuminariaHugoroTue, 28 Oct 2025 08:03:00 +0100https://ivanluminaria.com/ro/posts/postgresql/explain-analyze-postgresql/Tue, 28 Oct 2025 08:03:00 +0100https://ivanluminaria.com/ro/posts/postgresql/explain-analyze-postgresql/<p>Zilele trecute un coleg imi trimite o captura de ecran pe Teams. Un query care ruleaza pe o tabela de 2 milioane de randuri, 45 de secunde timp de executie. Imi scrie:</p> <blockquote> <p>&ldquo;Am facut EXPLAIN ANALYZE, dar nu inteleg ce e in neregula. Planul pare corect.&rdquo;</p> </blockquote> <p>Spoiler: planul nu era deloc corect. Optimizatorul alesese un <span class="glossary-tip" tabindex="0" data-glossary-desc="Nested Loop Join — strategia de join care scaneaza tabelul intern pentru fiecare rand al tabelului extern, ideala pentru seturi mici de date cu index." data-glossary-url="https://ivanluminaria.com/ro/glossary/nested-loop/" data-glossary-more="Citește mai mult →">nested loop</span> join unde era nevoie de un <span class="glossary-tip" tabindex="0" data-glossary-desc="Hash Join — strategie de join optimizata pentru volume mari de date, bazata pe o hash table construita in memorie." data-glossary-url="https://ivanluminaria.com/ro/glossary/hash-join/" data-glossary-more="Citește mai mult →">hash join</span> , iar motivul era banal — statistici neactualizate. Dar ca sa ajung acolo a trebuit sa citesc planul rand cu rand, si atunci mi-am dat seama ca majoritatea DBA-ilor pe care ii cunosc folosesc EXPLAIN ANALYZE ca pe un oracol binar: daca timpul e mare, query-ul e lent. Sfarsitul analizei.</p>