Postgres Pro
Downloads
Home   >   mailing lists

Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)
Date
Msg-id a312b665-79fb-4ee1-e9eb-e8ed9df5479f@iki.fi
Whole thread Raw
In response to Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)
List pgsql-hackers
Tree view 
I had a quick look at just the preliminary cleanup patches:

> 0001-BRIN-bloom-cleanup-20230218.patch

Looks good to me

> 0002-BRIN-minmax-multi-cleanup-20230218.patch

Looks good, although it would feel more natural to me to do it the other 
way round, and define 'matches' as 'bool matches', and use DatumGetBool.

Not new with this patch, but I find the 'matches' and 'matching' 
variables a bit strange. Wouldn't it be simpler to have just one variable?

> 0003-Introduce-bloom_filter_size-20230218.patch

Looks good

> 0004-Add-minmax-multi-inequality-tests-20230218.patch

Looks good

> +SELECT i/5 + mod(911 * i + 483, 25),
> +       i/10 + mod(751 * i + 221, 41)

Peculiar formulas. Was there a particular reason for these values?

- Heikki

pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Disable vacuuming to provide data history
Next
From: Tom Lane
Date:
Subject: Re: PG_FREE_IF_COPY extraneous in numeric_cmp?