Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)
Дата
Msg-id a312b665-79fb-4ee1-e9eb-e8ed9df5479f@iki.fi
обсуждение исходный текст
Ответ на Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список 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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Corey Huinker
Дата:
Сообщение: Re: Disable vacuuming to provide data history
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PG_FREE_IF_COPY extraneous in numeric_cmp?