On 03/04/2018 01:14 AM, Tomas Vondra wrote: > ... > > The one overflow issue I found in the patch is that the numeric > "distance" function does this: > > d = DirectFunctionCall2(numeric_sub, a2, a1); /* a2 - a1 */ > > PG_RETURN_FLOAT8(DirectFunctionCall1(numeric_float8, d)); > > which can overflow, of course. But that is not fatal - the index may get > inefficient due to non-optimal merging of ranges, but it will still > return correct results. But I think this can be easily improved by > passing not only the two values, but also minimum and maximum, and use > that to normalize the values to [0,1]. >
Attached is an updated patch series, addressing this possible overflow the way I proposed - by computing (a2 - a1) / (b2 - b1), which is guaranteed to produce a value between 0 and 1. The two new arguments are ignored for most "distance" functions, because those can't overflow or underflow in double precision AFAICS. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
0001-Pass-all-keys-to-BRIN-consistent-function-a-20180320.patch.gz
Description: application/gzip
0002-Move-IS-NOT-NULL-checks-to-bringetbitmap-20180320.patch.gz
Description: application/gzip
0003-BRIN-bloom-indexes-20180320.patch.gz
Description: application/gzip
0004-BRIN-multi-range-minmax-indexes-20180320.patch.gz
Description: application/gzip
