Re: Aggregate not using BRIN index on timestamp

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Aggregate not using BRIN index on timestamp
Дата
Msg-id 2667.1565020427@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Aggregate not using BRIN index on timestamp  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Aggregate not using BRIN index on timestamp  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Aggregate not using BRIN index on timestamp
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Aggregate not using BRIN index on timestamp