<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Performance on Antonio Cortés (DrZippie)</title><link>https://antoniocortes.com/tags/performance/</link><description>Recent content in Performance 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/performance/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><item><title>DuckDB: File Formats and Performance Optimizations</title><link>https://antoniocortes.com/en/duckdb-file-formats-performance-optimization/</link><pubDate>Sun, 01 Feb 2026 00:00:00 +0000</pubDate><guid>https://antoniocortes.com/en/duckdb-file-formats-performance-optimization/</guid><description>&lt;p&gt;Lately I&amp;rsquo;ve been working quite a bit with &lt;strong&gt;DuckDB&lt;/strong&gt;, and one of the things that interests me most is understanding how to optimize performance according to the file format we&amp;rsquo;re using.&lt;/p&gt;
&lt;p&gt;It&amp;rsquo;s not the same working with Parquet, compressed CSV, or uncompressed CSV. And the performance differences can be &lt;strong&gt;dramatic&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;Let&amp;rsquo;s review the key optimizations to keep in mind when working with different file formats in DuckDB.&lt;/p&gt;
&lt;h2 id="parquet-direct-query-or-load-first"&gt;Parquet: Direct Query or Load First?&lt;/h2&gt;
&lt;p&gt;DuckDB has advanced Parquet support, including the ability to query Parquet files directly without loading them into the database. But when should you do one or the other?&lt;/p&gt;</description></item></channel></rss>