Re: BRIN indexes - TRAP: BadArgument

Heikki Linnakangas <hlinnakangas@vmware.com>

From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Michael Paquier <michael.paquier@gmail.com>, David Rowley <dgrowleyml@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Jeff Janes <jeff.janes@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Erik Rijkers <er@xs4all.nl>, Emanuel Calvo <3manuek@esdebian.org>, Simon Riggs <simon@2ndquadrant.com>, Nicolas Barbier <nicolas.barbier@gmail.com>, "Claudio Freire" <klaussfreire@gmail.com>, Josh Berkus <josh@agliodbs.com>, "Andres Freund" <andres@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-11-09T09:18:01Z
Lists: pgsql-hackers
On 11/09/2014 08:06 AM, Michael Paquier wrote:
> On Sat, Nov 8, 2014 at 5:40 PM, David Rowley <dgrowleyml@gmail.com> wrote:
>> Please find attached another small fix. This time it's just a small typo in
>> the README, and just some updates to some, now outdated docs.
> Speaking about the feature... The index operators are still named with
> "minmax", wouldn't it be better to switch to "brin"?

All the built-in opclasses still implement the min-max policy - they 
store the min and max values. BRIN supports other kinds of opclasses, 
like storing a containing box for points, but no such opclasses have 
been implemented yet.

Speaking of which, Alvaro, any chance we could get such on opclass still 
included into 9.5? It would be nice to have one, just to be sure that 
nothing minmax-specific has crept into the BRIN code.

- Heikki


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>