Re: Minmax indexes

Erik Rijkers <er@xs4all.nl>

From: "Erik Rijkers" <er@xs4all.nl>
To: "Alvaro Herrera" <alvherre@2ndquadrant.com>
Cc: "Pg Hackers" <pgsql-hackers@postgresql.org>
Date: 2013-11-11T08:53:49Z
Lists: pgsql-hackers

Attachments

On Fri, November 8, 2013 21:11, Alvaro Herrera wrote:
>
> Here's a version 7 of the patch, which fixes these bugs and adds
> opclasses for a bunch more types (timestamp, timestamptz, date, time,
> timetz), courtesy of Martín Marqués.  It's also been rebased to apply
> cleanly on top of today's master branch.
>
> I have also added a selectivity function, but I'm not positive that it's
> very useful yet.
>
> [minmax-7.patch]

The earlier errors are indeed fixed; now, I've been trying with the attached test case but I'm unable to find a query that
improves with minmax index use.  (it gets used sometimes but speedup is negligable).

That probably means I'm doing something wrong; could you (or anyone) give some hints about use-case would be expected?

(Or is it just the unfinished selectivity function?)


Thanks,

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