Re: BRIN range operator class

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Emre Hasegeli <emre@hasegeli.com>
Cc: Andreas Karlsson <andreas@proxel.se>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2015-05-05T21:22:22Z
Lists: pgsql-hackers
Can you please explain what is the purpose of patch 07?  I'm not sure I
understand; are we trying to avoid having to add pg_amproc entries for
these operators and instead piggy-back on btree opclass definitions?
Not too much in love with that idea; I see that there is less tedium in
that the brin opclass definition is simpler.  One disadvantage is a 3x
increase in the number of syscache lookups to get the function you need,
unless I'm reading things wrong.  Maybe this is not performance critical.

Anyway I tried applying it on isolation, and found that it fails the
assertion that tests the "union" support proc in brininsert.  That
doesn't seem okay.  I mean, it's okay not to run the test for the
inclusion opclasses, but why does it now fail in minmax which was
previously passing?  Couldn't figure it out.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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>