Re: Aggregate not using BRIN index on timestamp - Mailing list pgsql-general

From Jeremy Finzel
Subject Re: Aggregate not using BRIN index on timestamp
Date
Msg-id CAMa1XUh4zy8uSLjQMH3UH_=bW84meeEduAci+_o2w_-paLgKRA@mail.gmail.com
Whole thread Raw
In response to Re: Aggregate not using BRIN index on timestamp  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Aggregate not using BRIN index on timestamp  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Aggregate not using BRIN index on timestamp  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-general
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

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Aggregate not using BRIN index on timestamp
Next
From: PegoraroF10
Date:
Subject: Re: why toasted is created when domain is used ?