Re: Aggregate not using BRIN index on timestamp

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> 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
> a bitmap scan to scan those. I'm not sure that this is a transformation
> that can be applied cleanly, since that thing I describe doesn't look to
> be a "subquery". But maybe it can -- I think you'd need a special
> executor node.

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 index
endpoint until it finds a visible tuple --- which, in the worst case,
can take a long time. It's not obvious to me what you'd do with
BRIN.

regards, tom lane