Horton

Re: Minmax indexes

Simon Riggs <simon@2ndquadrant.com>

View thread View on postgr.es
From: Simon Riggs <simon@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nicolas Barbier <nicolas.barbier@gmail.com>, Claudio Freire <klaussfreire@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, Andres Freund <andres@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-08-07T14:16:23Z
Lists: pgsql-hackers 
On 7 August 2014 14:53, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Aug 6, 2014 at 4:06 PM, Nicolas Barbier
> <nicolas.barbier@gmail.com> wrote:
>> 2014-08-06 Claudio Freire <klaussfreire@gmail.com>:
>>
>>> So, I like blockfilter a lot. I change my vote to blockfilter ;)
>>
>> +1 for blockfilter, because it stresses the fact that the "physical"
>> arrangement of rows in blocks matters for this index.
>
> I don't like that quite as well as summary, but I'd prefer either to
> the current naming.

Yes, "summary index" isn't good. I'm not sure where the block or the
filter part comes in though, so -1 to "block filter", not least
because it doesn't have a good abbreviation (bfin??).

A better description would be "block range index" since we are
indexing a range of blocks (not just one block). Perhaps a better one
would be simply "range index", which we could abbreviate to RIN or
BRIN.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

  1. Refactor per-page logic common to all redo routines to a new function.

  2. Reduce use of heavyweight locking inside hash AM.

  3. Scan the buffer pool just once, not once per fork, during relation drop.

  4. Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>