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
-
Refactor per-page logic common to all redo routines to a new function.
- f8f4227976a2 9.5.0 cited
-
Reduce use of heavyweight locking inside hash AM.
- 76837c1507cb 9.3.0 cited
-
Scan the buffer pool just once, not once per fork, during relation drop.
- ece01aae4792 9.2.0 cited
-
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
- 9e2a87b62db8 7.1.1 cited