<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Postgresql on Antonio Cortés (DrZippie)</title><link>https://antoniocortes.com/tags/postgresql/</link><description>Recent content in Postgresql on Antonio Cortés (DrZippie)</description><generator>Hugo</generator><language>es-es</language><lastBuildDate>Fri, 27 Feb 2026 09:58:56 +0100</lastBuildDate><atom:link href="https://antoniocortes.com/tags/postgresql/index.xml" rel="self" type="application/rss+xml"/><item><title>Cómo PostgreSQL estima tus consultas (y por qué a veces se equivoca)</title><link>https://antoniocortes.com/postgresql-statistics/</link><pubDate>Fri, 27 Feb 2026 00:00:00 +0000</pubDate><guid>https://antoniocortes.com/postgresql-statistics/</guid><description>&lt;p&gt;Toda consulta empieza con un plan. Toda consulta lenta probablemente empieza con uno malo. Y más a menudo de lo que crees, las estadísticas son las culpables.&lt;/p&gt;
&lt;p&gt;Pero ¿cómo funciona realmente? PostgreSQL no ejecuta la consulta para averiguarlo — estima el coste. Lee datos precalculados de &lt;code&gt;pg_class&lt;/code&gt; y &lt;code&gt;pg_statistic&lt;/code&gt; y hace los cálculos para encontrar la ruta más barata hacia tus datos.&lt;/p&gt;
&lt;p&gt;En el escenario ideal, los números que lee son precisos y obtienes el plan que esperas. Pero cuando están desactualizados, la situación se descontrola. El planificador estima 500 filas, planifica un nested loop, y se encuentra con 25,000. Lo que parecía un plan óptimo se convierte en una falla en cascada.&lt;/p&gt;</description></item><item><title>How PostgreSQL Estimates Your Queries (And Why It Sometimes Gets It Wrong)</title><link>https://antoniocortes.com/en/postgresql-statistics/</link><pubDate>Fri, 27 Feb 2026 00:00:00 +0000</pubDate><guid>https://antoniocortes.com/en/postgresql-statistics/</guid><description>&lt;p&gt;Every query starts with a plan. Every slow query probably starts with a bad one. And more often than not, the statistics are to blame. But how does it really work?&lt;/p&gt;
&lt;p&gt;PostgreSQL doesn&amp;rsquo;t run the query to find out — it estimates the cost. It reads pre-computed data from &lt;code&gt;pg_class&lt;/code&gt; and &lt;code&gt;pg_statistic&lt;/code&gt; and does the maths to figure out the cheapest path to your data.&lt;/p&gt;
&lt;p&gt;In the ideal scenario, the numbers read are accurate, and you get the plan you expect. But when they&amp;rsquo;re stale, the situation gets out of control. The planner estimates 500 rows, plans a nested loop, and hits 25,000. What seemed like an optimal plan turns into a cascading failure.&lt;/p&gt;</description></item></channel></rss>