On 03/02/2018 05:08 AM, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: >> On 2018-02-25 01:30:47 +0100, Tomas Vondra wrote: >>> Note: Currently, this only works with float8-based data types. >>> Supporting additional data types is not a big issue, but will >>> require extending the opclass with "subtract" operator (used to >>> compute distance between values when merging ranges). > >> Based on Tom's past stances I'm a bit doubtful he'd be happy with such a >> restriction. Note that something similar-ish also has come up in >> 0a459cec96. >
That restriction was lifted quite a long time ago, so now both index types support pretty much the same data types as the original BRIN (with the reltime/abstime exception, discussed in this thread earlier). >> I kinda wonder if there's any way to not have two similar but not >> equal types of logic here? > > Hm. I wonder what the patch intends to do with subtraction overflow, > or infinities, or NaNs. Just as with the RANGE patch, it does not > seem to me that failure is really an acceptable option. Indexes are > supposed to be able to index whatever the column datatype can store. > I admit that's something I haven't thought about very much. I'll look into that, of course, but the indexes are only using the deltas to pick which ranges to merge, so I think in the worst case it may results in sub-optimal index. But let me check what the RANGE patch did. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
