Horton

Re: BRIN indexes - TRAP: BadArgument

Greg Stark <stark@mit.edu>

View thread View on postgr.es
From: Greg Stark <stark@mit.edu>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Michael Paquier <michael.paquier@gmail.com>, David Rowley <dgrowleyml@gmail.com>, 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-09T17:06:02Z
Lists: pgsql-hackers 
On Sun, Nov 9, 2014 at 9:18 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> 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.

I'm trying to do a bloom filter Brin index. I'm already a bit puzzled
by a few things but I've just started so maybe it'll become clear.

From what I've seen so far it feels more likely there's the opposite.
There's some boilerplate that I'm doing that feels like it could be
pushed down into general Brin code since it'll be the same for every
access method.

-- 
greg

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>