| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys) |
| Date: | 2023-02-24 21:07:33 |
| Message-ID: | a312b665-79fb-4ee1-e9eb-e8ed9df5479f@iki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-02-24 22:16:16 | Re: PG_FREE_IF_COPY extraneous in numeric_cmp? |
| Previous Message | Corey Huinker | 2023-02-24 21:06:31 | Re: Disable vacuuming to provide data history |