Re: BRIN indexes - TRAP: BadArgument

Greg Stark wrote:
> It might be clearer to have an opclassinfo and a scaninfo which can
> store information in separate opc_opaque and scan_opaque fields with
> distinct liftetimes.
> 
> In the bloom filter case the longlived info is the (initial?) size of
> the bloom filter and the number of hash functions. But I still haven't
> determined how much it will cost to recalculate them. Right now
> they're just hard coded so it doesn't hurt to do it on every rescan
> but if it involves peeking at the index reloptions or stats that might
> be impractical.

Patches welcome :-)

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services