This series of posts traces the evolution from GIN to RUM to Extended RUM, showing how a single architectural idea—to store more in the index to do less work at query time—unlocks major performance improvements at each step.

Generalized Inverted Index (GIN) is PostgreSQL's answer to the question " how do I index composite values? " — including arrays, JSONB documents, tsvector, and any data type that decomposes into multiple keys per row.

The structure is conceptually simple:

Entry Tree (B-tree of keys) ├── "alice" → Posting List: [(0,1), (3,7), (5,2)] ├── "bob" → Posting List: [(0,2), (4,1)] ├── "carol" → Posting Tree (when list becomes too large for in-line storage)" │ └── B-tree of ItemPointers └── ...

Enter fullscreen mode

Exit fullscreen mode

For each indexed value, GIN calls extractValue to decompose it into keys. Each key gets an entry in the B-tree.…