Fix minmax-multi on infinite date/timestamp values Make sure that infinite values in date/timestamp columns are treated as if in infinite distance. Infinite values should not be merged with other values, leaving them as outliers. The code however returned distance 0 in this case, so that infinite values were merged first. While this does not break the index (i.e. it still produces correct query results), it may make it much less efficient.
We don't need explicit handling of infinite date/timestamp values when calculating distances, because those values are represented as extreme but regular values (e.g. INT64_MIN/MAX for the timestamp type). We don't need an exact distance, just a value that is much larger than distanced between regular values. With the added cast to double values, we can simply subtract the values. The regression test queries a value in the "gap" and checks the range was properly eliminated by the BRIN index. This only affects minmax-multi indexes on timestamp/date columns with infinite values, which is not very common in practice. The affected indexes may need to be rebuilt. Backpatch to 14, where minmax-multi indexes were introduced. Reported-by: Ashutosh Bapat Reviewed-by: Ashutosh Bapat, Dean Rasheed Backpatch-through: 14 Discussion: https://postgr.es/m/eef0ea8c-4aaa-8d0d-027f-58b1f35dd...@enterprisedb.com Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/52c934cc1f2ee947a76dfc395403b07c24bb6712 Modified Files -------------- src/backend/access/brin/brin_minmax_multi.c | 6 --- src/test/regress/expected/brin_multi.out | 57 +++++++++++++++++++++++++++++ src/test/regress/sql/brin_multi.sql | 39 ++++++++++++++++++++ 3 files changed, 96 insertions(+), 6 deletions(-)