Stores tsvector lexemes with positional information. Supports ordering by <=> operator and prefix search.

Stores hash of tsvector lexemes with positional information. Supports ordering by <=> operator, but does not support prefix search.

Stores tsvector lexemes with additional data of any type supported by RUM.

Stores tsvector lexemes with additional data of any type supported by RUM. Does not support prefix search.

Stores branches of query tree in additional information.

Stores anyarray elements with length of the array. Supports ordering by <=> operator.

Indexable operators: && @> <@ = %

Stores anyarray elements with additional data of any type supported by RUM.

Stores lexemes of the corresponding type with positional information. The type placeholder in the class name must be substituted by one of the following type names: int2, int4, int8, float4, float8, money, oid, timestamp, timestamptz, time, timetz, date, interval, macaddr, inet, cidr, text, varchar, char, bytea, bit, varbit, numeric.

rum_type_ops supports ordering by <=>, <=|, and |=> operators. This operator class can be used together with rum_tsvector_addon_ops, rum_tsvector_hash_addon_ops, and rum_anyarray_addon_ops operator classes.

Supported indexable operators depend on the data type:

Returns information about a RUM index metapage. For example:

SELECT * FROM rum_metapage_info('rum_index', 0);
-[ RECORD 1 ]----+-----------
pending_head     | 4294967295
pending_tail     | 4294967295
tail_free_size   | 0
n_pending_pages  | 0
n_pending_tuples | 0
n_total_pages    | 87
n_entry_pages    | 80
n_data_pages     | 6
n_entries        | 1650
version          | 0xC0DE0002

Returns information about a RUM index opaque area, such as leftlink and rightlink, maxoff, and freespace. The maxoff parameter is the number of elements stored in the page, it is used differently for different types of pages. The freespace column represents the amount of free space in the page. For example:

SELECT * FROM rum_page_opaque_info('rum_index', 10);
 leftlink | rightlink | maxoff | freespace | flags
----------+-----------+--------+-----------+--------
        6 |        11 |      0 |         0 | {leaf}
(1 row)

Returns information stored in internal pages of the entry tree. This information is extracted from IndexTuple. For example:

SELECT * FROM rum_internal_entry_page_items('rum_index', 1);
               key               | attrnum |     category     | down_link
---------------------------------+---------+------------------+-----------
 3d                              |       1 | RUM_CAT_NORM_KEY |         3
 6k                              |       1 | RUM_CAT_NORM_KEY |         2
 a8                              |       1 | RUM_CAT_NORM_KEY |         4
...
 Tue May 10 21:21:22.326724 2016 |       2 | RUM_CAT_NORM_KEY |        83
 Sat May 14 19:21:22.326724 2016 |       2 | RUM_CAT_NORM_KEY |        84
 Wed May 18 17:21:22.326724 2016 |       2 | RUM_CAT_NORM_KEY |        85
 +inf                            |         |                  |        86
(79 rows)

The RUM index, just like GIN, packs downlinks and keys in pairs of the (P_n, K_{n+1}) type on internal pages of the entry tree. Note that there is no key for P_0, it is assumed to be equal to -inf. Also, there is no downlink for the last key K_{n+1}, it is assumed to be the largest key, or high key, in the subtree to which the P_n link leads. In the rightmost page of each internal level of the entry tree, the key related to P_n does not have any value and is assumed to be equal to +inf.

Returns information that is stored in leaf pages of the entry tree. This information is extracted from compressed posting lists. For example:

SELECT * FROM rum_leaf_entry_page_items('rum_index', 10);
 key | attrnum |     category     | tuple_id | add_info_is_null | add_info | is_posting_tree  | posting_tree_root
-----+---------+------------------+----------+------------------+----------+------------------+--------------------
 ay  |       1 | RUM_CAT_NORM_KEY | (0,16)   | t                |          | f                |
 ay  |       1 | RUM_CAT_NORM_KEY | (0,23)   | t                |          | f                |
 ay  |       1 | RUM_CAT_NORM_KEY | (2,1)    | t                |          | f                |
...
 az  |       1 | RUM_CAT_NORM_KEY | (0,15)   | t                |          | f                |
 az  |       1 | RUM_CAT_NORM_KEY | (0,22)   | t                |          | f                |
 az  |       1 | RUM_CAT_NORM_KEY | (1,4)    | t                |          | f                |
...
 b9  |       1 | RUM_CAT_NORM_KEY |          |                  |          | t                |                  7
...
(1602 rows)

Each posting list is an IndexTuple that stores the key value and a compressed list of TIDs. When the rum_leaf_entry_page_items() function is called, the key value is attached to each TID for convenience, but in the page it is stored separately.

If the number of TIDs is too large, then a posting tree is used for storage rather than a posting list. In the example above, a posting tree is created for the key with the b9 value. The key in the posting tree is the TID. In this case, the magic number and the page number, which is the root of the posting tree, are stored inside IndexTuple instead of the posting list.

Returns information that is stored in internal pages of the posting tree. This information is extracted from arrays of the RumPostingItem structures. For example:

SELECT * FROM rum_internal_data_page_items('rum_index', 7);
 is_high_key | block_number | tuple_id | add_info_is_null | add_info
-------------+--------------+----------+------------------+----------
 t           |              | (0,0)    | t                |
 f           |            9 | (138,79) | t                |
 f           |            8 | (0,0)    | t                |
(3 rows)

Each internal page element of the posting tree contains the high key (TID) value for the child page and a link to this child page as well as additional information if it was added when creating the index.

At the beginning of am internal page of the posting tree, the high key of this page is always stored if it has the (0,0) value, this is equivalent to +inf. This is always the case if the page is the rightmost.

At the moment, RUM does not support storing data of the varlena data types in internal pages of the posting tree. These types of data can be stored only on leaf pages. Therefore, the following output is possible:

 is_high_key | block_number | tuple_id | add_info_is_null |                    add_info
-------------+--------------+----------+------------------+------------------------------------------------
...
 f           |           23 | (39,43)  | f                | varlena types in posting tree is not supported
 f           |           22 | (74,9)   | f                | varlena types in posting tree is not supported
...

Returns information that is stored in leaf pages of the posting tree. This information is extracted from compressed posting lists. For example:

SELECT * FROM rum_leaf_data_page_items('rum_idx', 9);
 is_high_key | tuple_id  | add_info_is_null | add_info
-------------+-----------+------------------+----------
 t           | (138,79)  | t                |
 f           | (0,9)     | t                |
 f           | (1,23)    | t                |
 f           | (3,5)     | t                |
 f           | (3,22)    | t                |

Unlike leaf pages of the entry tree, compressed posting lists are not stored in IndexTuple in the posting tree leaf pages. The high key is the largest key on the page.