0Pricing
PostgreSQL Performance & Query Optimization · Leçon

Index BRIN pour les grandes quantités de données séquentielles

Découvrez BRIN (Block Range INdexes), un type d’index minuscule, idéal pour les tables volumineuses dont les données sont naturellement ordonnées, comme les séries temporelles et les journaux en ajout uniquement.

Index BRIN pour les grandes quantités de données séquentielles est une leçon PostgreSQL Performance & Query Optimization gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage PostgreSQL Performance & Query Optimization, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours PostgreSQL Performance & Query Optimization comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

What is a BRIN Index?

A BRIN (Block Range INdex) stores summary information about ranges of physical table blocks instead of pointing at individual rows. Each entry covers many pages, so the index is extremely small.

How BRIN Differs from B-tree

A B-tree has one entry per row and can be large. A BRIN keeps just the min and max value for each block range.

  • B-tree: precise, big, great for random lookups
  • BRIN: approximate, tiny, great for range scans on ordered data

When BRIN Shines

BRIN works best when the column's values correlate with physical storage order. Classic cases:

  • Time-series tables ordered by inserted timestamp
  • Append-only logs
  • Large fact tables loaded in key order

Creating a BRIN Index

Use the USING brin clause. Notice how small and fast it is to build compared to a B-tree on the same column.

CREATE INDEX idx_events_ts_brin
ON events USING brin (created_at);

Querying Through a BRIN

A range filter lets the planner skip block ranges whose min/max cannot match, reading only the relevant pages.

EXPLAIN ANALYZE
SELECT * FROM events
WHERE created_at >= '2026-01-01'
  AND created_at <  '2026-02-01';

The pages_per_range Option

You can tune how many pages each summary entry covers. Smaller ranges make the index more precise but larger.

CREATE INDEX idx_events_ts_brin
ON events USING brin (created_at)
WITH (pages_per_range = 32);

Why Correlation Matters

If the column is not physically ordered, almost every block range will overlap the search value and BRIN will scan the whole table. Check correlation with the stats view.

SELECT attname, correlation
FROM pg_stats
WHERE tablename = 'events';

Summarizing New Data

BRIN entries for freshly inserted blocks may be unsummarized. Run this to summarize them so queries can prune those ranges.

SELECT brin_summarize_new_values('idx_events_ts_brin');

Size Comparison

On a billion-row table a B-tree might be tens of gigabytes while a BRIN is a few megabytes. Compare them directly.

SELECT pg_size_pretty(pg_relation_size('idx_events_ts_brin'));

Trade-offs to Remember

BRIN is not a free win:

  • Useless on randomly ordered columns
  • Slower for exact single-row lookups than B-tree
  • Needs periodic summarization of new blocks

Pick it when the table is huge and naturally ordered.

Maintaining BRIN over Updates

If existing rows are heavily updated, a block range's min/max may widen and lose precision over time. For volatile data, periodically rebuild the index to restore tight ranges.

REINDEX INDEX idx_events_ts_brin;

Quick Check

Test your BRIN knowledge.

Recap

You learned BRIN indexes:

  • They store min/max summaries per block range — tiny footprint
  • Ideal for large, physically ordered data like time-series
  • Created with USING brin; tune pages_per_range
  • Check correlation first; summarize new blocks
  • Avoid them on randomly ordered columns

Questions Fréquemment Posées

La leçon « Index BRIN pour les grandes quantités de données séquentielles » est-elle gratuite ?

Oui — le texte complet de « Index BRIN pour les grandes quantités de données séquentielles » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours PostgreSQL Performance & Query Optimization, passe à CoddyKit PRO. Le cours PostgreSQL Performance & Query Optimization comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Index BRIN pour les grandes quantités de données séquentielles » ?

Découvrez BRIN (Block Range INdexes), un type d’index minuscule, idéal pour les tables volumineuses dont les données sont naturellement ordonnées, comme les séries temporelles et les journaux en ajou… Tu pratiques PostgreSQL Performance & Query Optimization avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer PostgreSQL Performance & Query Optimization ?

Aucune expérience préalable n'est requise. PostgreSQL Performance & Query Optimization sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.

Combien de temps prend la leçon « Index BRIN pour les grandes quantités de données séquentielles » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon PostgreSQL Performance & Query Optimization ?

Oui. Chaque leçon PostgreSQL Performance & Query Optimization inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Index hash, GIN et GiST
  2. Index partiels et index d’expressions
  3. Index couvrants et parcours d’index uniquement
  4. Index BRIN pour les grandes quantités de données séquentielles
← Retour à PostgreSQL Performance & Query Optimization