Horton

Re: BRIN indexes - TRAP: BadArgument

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Greg Stark <stark@mit.edu>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>, Michael Paquier <michael.paquier@gmail.com>, David Rowley <dgrowleyml@gmail.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-11T13:04:03Z
Lists: pgsql-hackers 
Greg Stark wrote:
> It might be clearer to have an opclassinfo and a scaninfo which can
> store information in separate opc_opaque and scan_opaque fields with
> distinct liftetimes.
> 
> In the bloom filter case the longlived info is the (initial?) size of
> the bloom filter and the number of hash functions. But I still haven't
> determined how much it will cost to recalculate them. Right now
> they're just hard coded so it doesn't hurt to do it on every rescan
> but if it involves peeking at the index reloptions or stats that might
> be impractical.

Patches welcome :-)

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