Update RUM to PostgreSQL 18

1. Rename some definitions and structures due to conflicts after 8492feb98f6d
2. Add vacuum argument due to e5b0b0ce1509
3. Update README according to the documentation
4. Update Travis CI and other minor fixes

Author: Ekaterina Sokolova

.travis.yml

@@ -23,6 +23,8 @@ notifications:
         on_failure: always
 
 env:
+    - PG_VERSION=18
+    - PG_VERSION=18 LEVEL=hardcore
     - PG_VERSION=17
     - PG_VERSION=17 LEVEL=hardcore
     - PG_VERSION=16
@@ -32,6 +34,4 @@ env:
     - PG_VERSION=14
     - PG_VERSION=14 LEVEL=hardcore
     - PG_VERSION=13
-    - PG_VERSION=13 LEVEL=hardcore
     - PG_VERSION=12
-    - PG_VERSION=12 LEVEL=hardcore

README.md

@@ -8,29 +8,33 @@
 
 ## Introduction
 
-The **rum** module provides an access method to work with a `RUM` index. It is based
-on the `GIN` access method's code.
+The **rum** module provides access method to work with the `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:
 
 [![How RUM stores additional information](img/gin_rum.svg)](https://postgrespro.ru/docs/enterprise/current/rum?lang=en)
 
-A drawback of `RUM` is that it has slower build and insert times than `GIN`.
+The drawback of `RUM` is that it has slower build and insert time 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 generic WAL records.
 
 ## License
 

TODO

@@ -1,6 +1,6 @@
 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 of ItemPointer for use_alternative_order
+3. ItemPointer compression for indexes with order_by_attach
 4. Compression addInfo
 5. Remove FROM_STRATEGY ugly magick [done] 
 

src/rum.h

@@ -46,7 +46,7 @@ typedef struct RumPageOpaqueData
 	BlockNumber rightlink;		/* next page if any */
 	OffsetNumber maxoff;		/* number entries on RUM_DATA page: number of
 								 * heap ItemPointers on RUM_DATA|RUM_LEAF page
-								 * or number of PostingItems on RUM_DATA &
+								 * or number of RumPostingItems on RUM_DATA &
 								 * ~RUM_LEAF page. On RUM_LIST page, number of
 								 * heap tuples. */
 	OffsetNumber freespace;
@@ -150,19 +150,19 @@ typedef struct RumMetaPageData
  * (which is InvalidBlockNumber/0) as well as from all normal item
  * pointers (which have item numbers in the range 1..MaxHeapTuplesPerPage).
  */
-#define ItemPointerSetMin(p)  \
+#define RumItemPointerSetMin(p)  \
 	ItemPointerSet((p), (BlockNumber)0, (OffsetNumber)0)
-#define ItemPointerIsMin(p)  \
+#define RumItemPointerIsMin(p)  \
 	(RumItemPointerGetOffsetNumber(p) == (OffsetNumber)0 && \
 	 RumItemPointerGetBlockNumber(p) == (BlockNumber)0)
-#define ItemPointerSetMax(p)  \
+#define RumItemPointerSetMax(p)  \
 	ItemPointerSet((p), InvalidBlockNumber, (OffsetNumber)0xfffe)
-#define ItemPointerIsMax(p)  \
+#define RumItemPointerIsMax(p)  \
 	(RumItemPointerGetOffsetNumber(p) == (OffsetNumber)0xfffe && \
 	 RumItemPointerGetBlockNumber(p) == InvalidBlockNumber)
 #define ItemPointerSetLossyPage(p, b)  \
 	ItemPointerSet((p), (b), (OffsetNumber)0xffff)
-#define ItemPointerIsLossyPage(p)  \
+#define RumItemPointerIsLossyPage(p)  \
 	(RumItemPointerGetOffsetNumber(p) == (OffsetNumber)0xffff && \
 	 RumItemPointerGetBlockNumber(p) != InvalidBlockNumber)
 
@@ -175,7 +175,7 @@ typedef struct RumItem
 
 #define RumItemSetMin(item)  \
 do { \
-	ItemPointerSetMin(&((item)->iptr)); \
+	RumItemPointerSetMin(&((item)->iptr)); \
 	(item)->addInfoIsNull = true; \
 	(item)->addInfo = (Datum) 0; \
 } while (0)
@@ -188,12 +188,12 @@ typedef struct
 	/* We use BlockIdData not BlockNumber to avoid padding space wastage */
 	BlockIdData child_blkno;
 	RumItem		item;
-} PostingItem;
+} RumPostingItem;
 
-#define PostingItemGetBlockNumber(pointer) \
+#define RumPostingItemGetBlockNumber(pointer) \
 	BlockIdGetBlockNumber(&(pointer)->child_blkno)
 
-#define PostingItemSetBlockNumber(pointer, blockNumber) \
+#define RumPostingItemSetBlockNumber(pointer, blockNumber) \
 	BlockIdSet(&((pointer)->child_blkno), (blockNumber))
 
 /*
@@ -265,8 +265,8 @@ typedef signed char RumNullCategory;
  * Data (posting tree) pages
  */
 /*
- * FIXME -- Currently RumItem is placed as a pages right bound and PostingItem
- * is placed as a non-leaf pages item. Both RumItem and PostingItem stores
+ * FIXME -- Currently RumItem is placed as a pages right bound and RumPostingItem
+ * is placed as a non-leaf pages item. Both RumItem and RumPostingItem stores
  * AddInfo as a raw Datum, which is bogus. It is fine for pass-by-value
  * attributes, but it isn't for pass-by-reference, which may have variable
  * length of data. This AddInfo is used only by order_by_attach indexes, so it
@@ -278,12 +278,12 @@ typedef signed char RumNullCategory;
 #define RumDataPageGetData(page)	\
 	(PageGetContents(page) + MAXALIGN(sizeof(RumItem)))
 #define RumDataPageGetItem(page,i)	\
-	(RumDataPageGetData(page) + ((i)-1) * sizeof(PostingItem))
+	(RumDataPageGetData(page) + ((i)-1) * sizeof(RumPostingItem))
 
 #define RumDataPageGetFreeSpace(page)	\
 	(BLCKSZ - MAXALIGN(SizeOfPageHeaderData) \
 	 - MAXALIGN(sizeof(RumItem)) /* right bound */ \
-	 - RumPageGetOpaque(page)->maxoff * sizeof(PostingItem) \
+	 - RumPageGetOpaque(page)->maxoff * sizeof(RumPostingItem) \
 	 - MAXALIGN(sizeof(RumPageOpaqueData)))
 
 #define RumMaxLeafDataItems \
@@ -513,7 +513,7 @@ typedef struct RumBtreeData
 	uint32		nitem;
 	uint32		curitem;
 
-	PostingItem pitem;
+	RumPostingItem pitem;
 }	RumBtreeData;
 
 extern RumBtreeStack *rumPrepareFindLeafPage(RumBtree btree, BlockNumber blkno);

src/rumbtree.c

@@ -102,7 +102,7 @@ rumReFindLeafPage(RumBtree btree, RumBtreeStack * stack)
 		 * item pointer is less than item pointer previous to rightmost.
 		 */
 		if (compareRumItem(btree->rumstate, btree->entryAttnum,
-			  &(((PostingItem *) RumDataPageGetItem(page, maxoff - 1))->item),
+			  &(((RumPostingItem *) RumDataPageGetItem(page, maxoff - 1))->item),
 								   &btree->items[btree->curitem]) >= 0)
 		{
 			break;