Bug in processing conditions on multi-column BRIN indexes

Hi,

While working on the BRIN SK_SEARCHARRAY patch I noticed a silly bug in
handling clauses on multi-column BRIN indexes, introduced in PG13.

Consider a simple table with two columns (a,b) and a multi-columns BRIN
index on them:

    create table t (a int, b int);

    insert into t
    select
        mod(i,10000) + 100 * random(),
        mod(i,10000) + 100 * random()
    from generate_series(1,1000000) s(i);

    create index on t using brin(a int4_minmax_ops, b int4_minmax_ops)
      with (pages_per_range=1);

Let's run a query with condition on "a":

    select * from t where a = 500;
                               QUERY PLAN
    -----------------------------------------------------------------
     Bitmap Heap Scan on t (actual rows=97 loops=1)
       Recheck Cond: (a = 500)
       Rows Removed by Index Recheck: 53189
       Heap Blocks: lossy=236
       ->  Bitmap Index Scan on t_a_b_idx (actual rows=2360 loops=1)
             Index Cond: (a = 500)
     Planning Time: 0.075 ms
     Execution Time: 8.263 ms
    (8 rows)

Now let's add another condition on b:

    select * from t where a = 500 and b < 800;

                               QUERY PLAN
    -----------------------------------------------------------------
     Bitmap Heap Scan on t (actual rows=97 loops=1)
       Recheck Cond: ((a = 500) AND (b < 800))
       Rows Removed by Index Recheck: 101101
       Heap Blocks: lossy=448
       ->  Bitmap Index Scan on t_a_b_idx (actual rows=4480 loops=1)
             Index Cond: ((a = 500) AND (b < 800))
     Planning Time: 0.085 ms
     Execution Time: 14.989 ms
    (8 rows)

Well, that's wrong. With one condition we accessed 236 pages, and with
additional condition - which should reduce the number of heap pages - we
accessed 448 pages.

The problem is in bringetbitmap(), which failed to combine the results
from consistent function correctly (and also does not abort early).

Here's a patch for that, I'll push it shortly after a bit more testing.


regard

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company