<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Execution-Plan on Ivan Luminaria</title><link>https://ivanluminaria.com/ro/tags/execution-plan/</link><description>Recent content in Execution-Plan on Ivan Luminaria</description><generator>Hugo</generator><language>ro</language><lastBuildDate>Tue, 23 Dec 2025 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/ro/tags/execution-plan/index.xml" rel="self" type="application/rss+xml"/><item><title>Oracle Partitioning: când 2 miliarde de rânduri nu mai încap într-o interogare</title><link>https://ivanluminaria.com/ro/posts/oracle/oracle-partitioning/</link><pubDate>Tue, 23 Dec 2025 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/ro/posts/oracle/oracle-partitioning/</guid><description>&lt;p&gt;Două miliarde de rânduri. Nu este un număr la care ajungi într-o zi. Durează ani de tranzacții, mișcări, înregistrări zilnice care se acumulează. Și în tot acest timp baza de date funcționează, interogările răspund, rapoartele ies. Apoi într-o zi cineva deschide un ticket: „raportul lunar durează patru ore.&amp;quot;&lt;/p&gt;
&lt;p&gt;Patru ore. Pentru un raport care cu șase luni înainte dura douăzeci de minute.&lt;/p&gt;
&lt;p&gt;Nu este un bug. Nu este o problemă de rețea sau de stocare lentă. Este fizica datelor: când o tabelă crește peste un anumit prag, abordările care funcționau nu mai funcționează. Și dacă nu ai proiectat structura să gestioneze acea creștere, baza de date face singurul lucru pe care îl poate face: citește totul.&lt;/p&gt;</description></item><item><title>EXPLAIN ANALYZE nu e suficient: cum sa citesti cu adevarat un plan de executie PostgreSQL</title><link>https://ivanluminaria.com/ro/posts/postgresql/explain-analyze-postgresql/</link><pubDate>Tue, 28 Oct 2025 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/ro/posts/postgresql/explain-analyze-postgresql/</guid><description>&lt;p&gt;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:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;ldquo;Am facut EXPLAIN ANALYZE, dar nu inteleg ce e in neregula. Planul pare corect.&amp;rdquo;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Spoiler: planul nu era deloc corect. Optimizatorul alesese un &lt;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 →"&gt;nested loop&lt;/span&gt;
 join unde era nevoie de un &lt;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 →"&gt;hash join&lt;/span&gt;
, 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.&lt;/p&gt;</description></item></channel></rss>