Re: Aggregate not using BRIN index on timestamp

>
> Yes: BRIN indexes don't provide any ordering information. A btree
> index on created_at could be used to optimize this query, but without
> one of those, seqscanning the whole table is the only possibility.
>

Thanks Tom. So, this is a very general question, but would it be possible
to develop that feature into BRIN, given what it stores? Even if it does
not have ordering information, doesn't it know which blocks would contain
the lowest values, so it could choose to do a "bitmap scan ordered sort" or
something, depending on the number of rows sought? Or is the problem that
it has no way of determining what value actually would be the "minimum"
without the query specifying a particular date, such as less than
"2013-04-01"?

Thanks!
Jeremy