Horton

Re: Minmax indexes

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Nicolas Barbier <nicolas.barbier@gmail.com>, Claudio Freire <klaussfreire@gmail.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-07T22:39:21Z
Lists: pgsql-hackers

Attachments

Simon Riggs wrote:

> 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.

Seems a lot of people liked BRIN.  I will be adopting that by renaming
files and directories soon.

Here's v14.  I fixed a few bugs; most notably, queries with IS NULL and
IS NOT NULL now work correctly.  Also I made the pageinspect extension
be able to display existing index tuples (I had disabled that when
generalizing the opclass stuff).  It only works with minmax opclasses
for now; it should be easy to fix if/when we add more stuff though.

I also added some docs.  These are not finished by any means.  They 
talk about the index using the BRIN term.

All existing opclasses were renamed to "<type>_minmax_ops".

-- 
Álvaro Herrera                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>