on_failure:always

env:

-PG_VERSION=18

-PG_VERSION=18 LEVEL=hardcore

-PG_VERSION=17

-PG_VERSION=17 LEVEL=hardcore

-PG_VERSION=16

-PG_VERSION=14

-PG_VERSION=14 LEVEL=hardcore

-PG_VERSION=13

-PG_VERSION=13 LEVEL=hardcore

-PG_VERSION=12

-PG_VERSION=12 LEVEL=hardcore

RUM is released under the PostgreSQL License, a liberal Open Source license, similar to the BSD or MIT licenses.

Portions Copyright (c) 2015-2024, Postgres Professional

Portions Copyright (c) 2015-2025, Postgres Professional

Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group

Portions Copyright (c) 1994, The Regents of the University of California

The**rum** module providesanaccess method to work witha`RUM`index. It is based

on the`GIN` access method's code.

The**rum** module provides access method to work withthe`RUM`indexes. It is based

on the`GIN` access method code.

A`GIN` index allows performing fast full-text search using`tsvector` and

`tsquery` types. But full-text search with a GIN index has several problems:

`GIN` index allows you to perform fast full-text search using`tsvector` and

`tsquery` types. However, full-text search with`GIN` index has some performance

issues because positional and other additional information is not stored.

- Slow ranking. It needs positional information about lexemes to do ranking. A`GIN`

index doesn't store positions of lexemes. So after index scanning, we need an

additional heap scan to retrieve lexeme positions.

- Slow phrase search with a`GIN` index. This problem relates to the previous

problem. It needs positional information to perform phrase search.

- Slow ordering by timestamp. A`GIN` index can't store some related information

in the index with lexemes. So it is necessary to perform an additional heap scan.

`RUM` solves these issues by storing additional information in a posting tree.

As compared to`GIN`,`RUM` index has the following benefits:

`RUM` solves these problems by storing additional information in a posting tree.

For example, positional information of lexemes or timestamps. You can get an

idea of`RUM` with the following diagram:

- Faster ranking. Ranking requires positional information. And after the

index scan we do not need an additional heap scan to retrieve lexeme positions

because`RUM` index stores them.

- Faster phrase search. This improvement is related to the previous one as

phrase search also needs positional information.

- Faster ordering by timestamp.`RUM` index stores additional information together

with lexemes, so it is not necessary to perform a heap scan.

- A possibility to perform depth-first search and therefore return first

results immediately.

You can get an idea of`RUM` with the following diagram:

[](https://postgrespro.ru/docs/enterprise/current/rum?lang=en)

A drawback of`RUM` is that it has slower build and inserttimes than`GIN`.

The drawback of`RUM` is that it has slower build and inserttime as compared to`GIN`

This is because we need to store additional information besides keys and because

`RUM`uses generic Write-Ahead Log (WAL) records.

because`RUM`stores additional information together with keys and uses genericWAL records.

1. with naturalOrder=true make scan the rest to be consistent with seqscan [done]

2. add leftlink to data page to privide backward scan on index (<=| op) [done]

3.Compression ofItemPointer foruse_alternative_order

3. ItemPointercompressionforindexes with order_by_attach

4. Compression addInfo

5. Remove FROM_STRATEGY ugly magick [done]

BlockNumberrightlink;/* next page if any */

OffsetNumbermaxoff;/* number entries on RUM_DATA page: number of

OffsetNumberfreespace;

#defineItemPointerSetMin(p) \

#defineRumItemPointerSetMin(p) \

ItemPointerSet((p), (BlockNumber)0, (OffsetNumber)0)

#defineItemPointerIsMin(p) \

#defineRumItemPointerIsMin(p) \

(RumItemPointerGetOffsetNumber(p) == (OffsetNumber)0 && \

RumItemPointerGetBlockNumber(p) == (BlockNumber)0)

#defineItemPointerSetMax(p) \

#defineRumItemPointerSetMax(p) \

ItemPointerSet((p), InvalidBlockNumber, (OffsetNumber)0xfffe)

#defineItemPointerIsMax(p) \

#defineRumItemPointerIsMax(p) \

(RumItemPointerGetOffsetNumber(p) == (OffsetNumber)0xfffe && \

RumItemPointerGetBlockNumber(p) == InvalidBlockNumber)

#defineItemPointerSetLossyPage(p,b) \

ItemPointerSet((p), (b), (OffsetNumber)0xffff)

#defineItemPointerIsLossyPage(p) \

#defineRumItemPointerIsLossyPage(p) \

(RumItemPointerGetOffsetNumber(p) == (OffsetNumber)0xffff && \

RumItemPointerGetBlockNumber(p) != InvalidBlockNumber)

#defineRumItemSetMin(item) \

do { \

ItemPointerSetMin(&((item)->iptr)); \

RumItemPointerSetMin(&((item)->iptr)); \

(item)->addInfoIsNull = true; \

(item)->addInfo = (Datum) 0; \

} while (0)

BlockIdDatachild_blkno;

RumItemitem;

}PostingItem;

}RumPostingItem;

#definePostingItemGetBlockNumber(pointer) \

#defineRumPostingItemGetBlockNumber(pointer) \

BlockIdGetBlockNumber(&(pointer)->child_blkno)

#definePostingItemSetBlockNumber(pointer,blockNumber) \

#defineRumPostingItemSetBlockNumber(pointer,blockNumber) \

BlockIdSet(&((pointer)->child_blkno), (blockNumber))

#defineRumDataPageGetData(page)\

(PageGetContents(page) + MAXALIGN(sizeof(RumItem)))

#defineRumDataPageGetItem(page,i)\

(RumDataPageGetData(page) + ((i)-1) * sizeof(PostingItem))

(RumDataPageGetData(page) + ((i)-1) * sizeof(RumPostingItem))

#defineRumDataPageGetFreeSpace(page)\

(BLCKSZ - MAXALIGN(SizeOfPageHeaderData) \

- MAXALIGN(sizeof(RumItem))/* right bound */ \

-RumPageGetOpaque(page)->maxoff*sizeof(PostingItem) \

-RumPageGetOpaque(page)->maxoff*sizeof(RumPostingItem) \

-MAXALIGN(sizeof(RumPageOpaqueData)))

#defineRumMaxLeafDataItems \

uint32nitem;

uint32curitem;

PostingItempitem;

RumPostingItempitem;

}RumBtreeData;

externRumBtreeStack*rumPrepareFindLeafPage(RumBtreebtree,BlockNumberblkno);

if (compareRumItem(btree->rumstate,btree->entryAttnum,

&(((PostingItem*)RumDataPageGetItem(page,maxoff-1))->item),

&(((RumPostingItem*)RumDataPageGetItem(page,maxoff-1))->item),

&btree->items[btree->curitem]) >=0)

{

break;