https://ivanluminaria.com/es/tags/optimizer/Recent content in Optimizer on Ivan LuminariaHugoesTue, 28 Oct 2025 08:03:00 +0100https://ivanluminaria.com/es/posts/postgresql/explain-analyze-postgresql/Tue, 28 Oct 2025 08:03:00 +0100https://ivanluminaria.com/es/posts/postgresql/explain-analyze-postgresql/<p>El otro dia un colega me manda una captura de pantalla por Teams. Una query corriendo sobre una tabla de 2 millones de filas, 45 segundos de ejecucion. Me escribe:</p> <blockquote> <p>&ldquo;Hice EXPLAIN ANALYZE, pero no entiendo que esta mal. El plan parece correcto.&rdquo;</p> </blockquote> <p>Spoiler: el plan no era correcto en absoluto. El optimizer habia elegido un <span class="glossary-tip" tabindex="0" data-glossary-desc="Nested Loop Join — la estrategia de join que escanea la tabla interna por cada fila de la tabla externa, ideal para datasets pequenos con indice." data-glossary-url="https://ivanluminaria.com/es/glossary/nested-loop/" data-glossary-more="Leer más →">nested loop</span> join donde hacia falta un <span class="glossary-tip" tabindex="0" data-glossary-desc="Hash Join — estrategia de join optimizada para grandes volumenes de datos, basada en una hash table construida en memoria." data-glossary-url="https://ivanluminaria.com/es/glossary/hash-join/" data-glossary-more="Leer más →">hash join</span> , y la razon era trivial — estadisticas desactualizadas. Pero para llegar a eso tuve que leer el plan linea por linea, y ahi me di cuenta de que la mayoria de los DBA que conozco usan EXPLAIN ANALYZE como un oraculo binario: si el tiempo es alto, la query es lenta. Fin del analisis.</p>