On 2019-Aug-05, Tom Lane wrote:
> FWIW, I suspect the hard part would be dealing with cases where the
> extremal ranges (according to the index) contain no live tuples
> (according to the query's snapshot). The btree case handles the
> invisible-tuples problem by continuing a scan started at the
Alvaro Herrera writes:
> For btrees, we have planagg.c which transforms min() and max() into
> subqueries (SELECT .. WHERE ... ORDER BY .. LIMIT 1).
> In a BRIN index, you could execute the search by scanning the index to
> determine which ranges contain the least/greatest values, and then using
On 2019-Aug-05, Jeremy Finzel wrote:
> 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
Jeremy Finzel writes:
> Thanks Tom. So, this is a very general question, but would it be possible
> to develop that feature into BRIN, given what it stores?
You'd need somebody who knows more about BRIN than me to opine on that.
regards, tom lane
>
> 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 develo
Jeremy Finzel writes:
> I have a very large table with 4 billion rows and a BRIN index on timestamp
> spanning from 2013 to present. I am running this simple query:
> SELECT MIN(created_at) FROM table;
> It is choosing a parallel seq scan as opposed to a BRIN bitmap scan.
> I can provide more in
Hello -
I have started to make much more use of BRIN indexes on timestamp fields on
tables which are insert-only. I have seen great performance with these and
of course far less overhead.
However, I am noticing that a simple aggregate is not using the index. I
don't find anything obvious in the
