Search Postgresql Archives

Re: Aggregate not using BRIN index on timestamp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alvaro Herrera <alvherre@xxxxxxxxxxxxxxx> 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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux