Horton

Re: BRIN indexes - TRAP: BadArgument

Erik Rijkers <er@xs4all.nl>

View thread View on postgr.es
From: "Erik Rijkers" <er@xs4all.nl>
To: "Alvaro Herrera" <alvherre@2ndquadrant.com>
Cc: "Heikki Linnakangas" <hlinnakangas@vmware.com>, "Emanuel Calvo" <3manuek@esdebian.org>, "Simon Riggs" <simon@2ndquadrant.com>, "Robert Haas" <robertmhaas@gmail.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-09-26T16:12:22Z
Lists: pgsql-hackers 
On Tue, September 23, 2014 21:04, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> [minmax-19.patch]
> [minmax-19a.patch]

Although admittedly it is not directly likely for us to need it, and although I see that there is a BRIN Extensibility
chapter added (good!), I am still a bit surprised by the absence of a built-in BRIN operator class for bigint, as the BRIN
index type is specifically useful for huge tables (where after all huge values are more likely to occur).

Will a brin int8 be added operator class for 9.5? (I know, quite some time left...)

(btw, so far the patch proves quite stable under my abusive testing...)


thanks,


Erik Rijkers

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>