<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Partitioning on Ivan Luminaria</title><link>https://ivanluminaria.com/en/tags/partitioning/</link><description>Recent content in Partitioning on Ivan Luminaria</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 23 Dec 2025 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/en/tags/partitioning/index.xml" rel="self" type="application/rss+xml"/><item><title>Oracle Partitioning: when 2 billion rows no longer fit in a query</title><link>https://ivanluminaria.com/en/posts/oracle/oracle-partitioning/</link><pubDate>Tue, 23 Dec 2025 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/en/posts/oracle/oracle-partitioning/</guid><description>&lt;p&gt;Two billion rows. You do not reach that number in a day. It takes years of transactions, movements, daily records piling up. And for all that time the database works, queries respond, reports come out. Then one day someone opens a ticket: &amp;ldquo;the monthly report takes four hours.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Four hours. For a report that six months earlier took twenty minutes.&lt;/p&gt;
&lt;p&gt;It is not a bug. It is not a network issue or slow storage. It is the physics of data: when a table grows beyond a certain threshold, the approaches that worked stop working. And if you did not design the structure to handle that growth, the database does the only thing it can: read everything.&lt;/p&gt;</description></item></channel></rss>