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

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



pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Aggregate not using BRIN index on timestamp
Next
From: Alvaro Herrera
Date:
Subject: Re: Aggregate not using BRIN index on timestamp