gin/jsonb_ops (family)

Description

GIN operator family containing 1 classes, 6 operator strategies and 5 support functions in this source build.

Object kind

Operator family

Index AM

GIN

Usage

gin/jsonb_ops

Operator classes and families

An index definition can specify an operator class for each column of an index.

The operator class identifies the operators to be used by the index for that column. For example, a B-tree index on the type int4 would use the int4_ops class; this operator class includes comparison functions for values of type int4 . In practice the default operator class for the column's data type is usually sufficient. The main reason for having operator classes is that for some data types, there could be more than one meaningful index behavior. For example, we might want to sort a complex-number data type either by absolute value or by real part. We could do this by defining two operator classes for the data type and then selecting the proper class when making an index. The operator class determines the basic sort ordering (which can then be modified by adding sort options COLLATE , ASC / DESC and/or NULLS FIRST / NULLS LAST ).

There are also some built-in operator classes besides the default ones:

Specific manual guidance

For these operators, a GIN index extracts clauses of the form accessors_chain == constant out of the jsonpath pattern, and does the index search based on the keys and values mentioned in these clauses. The accessors chain may include . key , [*] , and [ index ] accessors. The jsonb_ops operator class also supports .* and .** accessors, but the jsonb_path_ops operator class does not.

Although the jsonb_path_ops operator class supports only queries with the @> , @? and @@ operators, it has notable performance advantages over the default operator class jsonb_ops . A jsonb_path_ops index is usually much smaller than a jsonb_ops index over the same data, and the specificity of searches is better, particularly when queries contain keys that appear frequently in the data. Therefore search operations typically perform better than with the default operator class.

The technical difference between a jsonb_ops and a jsonb_path_ops GIN index is that the former creates independent index items for each key and value in the data, while the latter creates index items only for each value in the data. [7] Basically, each jsonb_path_ops index item is a hash of the value and the key(s) leading to it; for example to index {"foo": {"bar": "baz"}} , a single index item would be created incorporating all three of foo , bar , and baz into the hash value. Thus a containment query looking for this structure would result in an extremely specific index search; but there is no way at all to find out whether foo appears as a key. On the other hand, a jsonb_ops index would create three index items representing foo , bar , and baz separately; then to do the containment query, it would look for rows containing all three of these items. While GIN indexes can perform such an AND search fairly efficiently, it will still be less specific and slower than the equivalent jsonb_path_ops search, especially if there are a very large number of rows containing any single one of the three index items.

Related entries

• GIN Index AM

Documentation and source

• Matching PostgreSQL source archive
• PostgreSQL 18 English manual: indexes-opclass.html
• PostgreSQL 18 English manual: catalog-pg-opfamily.html
• PostgreSQL 18 English manual: catalog-pg-amop.html
• PostgreSQL 18 English manual: catalog-pg-amproc.html
• PostgreSQL 18 English manual: datatype-json.html

Compare versions

PostgreSQL 17 → 18: unchanged.

Compares recorded interfaces and attributes. Source fingerprints and build metadata are excluded; an absent sample is not proof of the introduction or removal release.

Related entries

• gin/array_ops (family)
• gin/jsonb_path_ops (family)
• gin/tsvector_ops (family)