<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>BRIN on Nalar</title>
    <link>https://nalar.dev/tags/brin/</link>
    <description>Recent content in BRIN on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 15 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/brin/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>PostgreSQL BRIN Unsummarized Ranges Delay Page Skipping</title>
      <link>https://nalar.dev/postgresql-brin-unsummarized-ranges-delay-page-skipping/</link>
      <pubDate>Tue, 15 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/postgresql-brin-unsummarized-ranges-delay-page-skipping/</guid>
      <description>&lt;p&gt;A BRIN index does not maintain one index tuple for every heap row. It stores summary data for groups of adjacent heap pages. That compact structure also creates a maintenance boundary: a newly allocated block range can exist without a summary tuple, leaving the index without summary data for that range until a summarization event occurs.&lt;/p&gt;&#xA;&lt;p&gt;This state matters most on append-heavy tables. Existing summarized ranges continue to track inserted values, but a new range is not automatically given its initial summary under the default settings.&lt;/p&gt;</description>
    </item>
    <item>
      <title>PostgreSQL BRIN Unsummarized Ranges Expand Heap Rechecks</title>
      <link>https://nalar.dev/postgresql-brin-unsummarized-ranges-expand-heap-rechecks/</link>
      <pubDate>Tue, 15 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/postgresql-brin-unsummarized-ranges-expand-heap-rechecks/</guid>
      <description>&lt;p&gt;A PostgreSQL BRIN index can contain block ranges with no summary tuple. Newly completed ranges do not receive an initial summary merely because inserts crossed the range boundary. Until maintenance creates that summary, a BRIN scan cannot use range metadata to exclude the affected heap pages.&lt;/p&gt;&#xA;&lt;p&gt;This state is normal index maintenance behavior rather than index corruption. It follows from BRIN&amp;rsquo;s compact design: the index stores summaries for groups of adjacent heap pages instead of one entry per indexed row.&lt;/p&gt;</description>
    </item>
    <item>
      <title>PostgreSQL BRIN Indexes Summarize Block Ranges</title>
      <link>https://nalar.dev/postgresql-brin-indexes-summarize-block-ranges/</link>
      <pubDate>Mon, 14 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/postgresql-brin-indexes-summarize-block-ranges/</guid>
      <description>&lt;p&gt;A PostgreSQL BRIN index does not store one index entry for every indexed row. It stores summary data for consecutive ranges of heap blocks. That distinction gives BRIN a very different cost and selectivity profile from a B-tree.&lt;/p&gt;&#xA;&lt;p&gt;The access method fits large tables where indexed values tend to follow heap location. Timestamped append-heavy data is a common shape: older values tend to occupy earlier blocks and newer values tend to occupy later blocks. A range predicate can then eliminate many block ranges using compact summary data.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
