> Currently, one issue you're going to face is that brin doesn't rescan a
range to
> find the tighest possible summary tuple.
That's going to be an issue I think, thanks for mentioning it. We'd need
some sort of mechanism for achieving this without a complete REINDEX, even
if it only reset the min/max when all the blocks in the range are entirely
cleared out. Ah well :)
> Another issue is how to find the best possible ordering. For minmax
> opclasses it's easy, but for other opclass designs it's less clear what to
do.
> Even for minmax you need to find some way to communicate to the system
> what's the order to follow ...
Do you mean the ordering for the clustered table tuples or the ordering of
index tuples in the BRIN index? I'm the former because I'm also assuming you
always scan an entire BRIN index as there isn't a trivial way of optimizing
the index scan for ranges (unless you 'granulate' the ranges along the lines
of this: http://dba.stackexchange.com/a/22295/1396)?
If you mean the clustering order, for the use cases I'm concerned with it
isn't important - as long as tuples with the same cluster key gravitate
towards the same blocks, it often doesn't matter what order those blocks are
in because the main mission is to reduce the number of blocks scanned.