opt: enable usage of inverted index with OR clauses

[andy-kimball]

This is a new issue derived from comments made by @Bessonov on issue #2142.

CREATE TABLE t (
	id UUID NOT NULL DEFAULT gen_random_uuid(),
	perms JSONB NOT NULL,
	CONSTRAINT "primary" PRIMARY KEY (id ASC),
	INVERTED INDEX ix_perms (perms)
);

> explain (opt) select * from t where perms->'scope'->'xx2000' @> '[{"type":"column"}]' or perms->'scope'->'xx4000' @> '[{"type":"column"}]';
                                                               text                                                               
+--------------------------------------------------------------------------------------------------------------------------------+
  select                                                                                                                          
   ├── scan t                                                                                                                     
   └── filters                                                                                                                    
        └── (perms @> '{"scope": {"xx2000": [{"type": "column"}]}}') OR (perms @> '{"scope": {"xx4000": [{"type": "column"}]}}')

EXPECTED: The ix_perms index should be used.
ACTUAL: The primary index is used instead.

We could fix this in one of two ways:

1. Extend the work for sql: better query planning for OR expressions #2142 to use UNION in the case where both OR predicates reference the same columns. With regular indexes, that's not necessary because index selection code creates multiple spans for this case. But with inverted indexes, multiple spans can create duplicates.
2. Update inverted index selection code to generate multiple spans; in this case, we'd need to add a DISTINCT operator to remove any duplicates.

[steeling]

Do you know what the SQL query would be that takes advantage of this feature on inverted indexes? Would it be:

SELECT * FROM t WHERE t.int_arr && ARRAY[1,2,3];

[mgartner]

Initially, this feature would support using inverted indexes when there is an explicit OR disjunction, like:

SELECT * FROM t WHERE t.int_arr @> ARRAY[1] OR t.int_arr @> ARRAY[2]

&& is the "overlap" operator, which is an implicit disjunction—it returns true if the left and right have at least one element in common. We should be able to extend this disjunction work to also optimize the && operator.

Ideally the new "InvertedExpr" (work in progress) can handle an arbitrary number of disjunctions, which should make this straight forward. If necessary, we could normalize a && ARRAY[1, 2] to a @> ARRAY[1] OR a @> ARRAY[2].

[mgartner]

There are a handful of improvement to inverted indexes that will be released in 21.1, including index accelerating disjunctions on the same inverted-indexed column, e.g. j->'a' = '1' OR j->'a' = '2'.

However, we do not currently index accelerate expressions of the form j->'a' @> '1', which are present in the query at the top of this issue. I've opened #61430 to track this enhancement separately.