Horton

Re: Minmax indexes

Jeff Janes <jeff.janes@gmail.com>

View thread View on postgr.es
From: Jeff Janes <jeff.janes@gmail.com>
To: Erik Rijkers <er@xs4all.nl>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2013-11-11T17:15:53Z
Lists: pgsql-hackers 
On Mon, Nov 11, 2013 at 12:53 AM, Erik Rijkers <er@xs4all.nl> wrote:

> 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).
>


Your data set seems to be completely random.  I believe that minmax indices
would only be expected to be useful when the data is clustered.  Perhaps
you could try it on a table where it is populated something like
 i+random()/10*max_i.

Cheers,

Jeff

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>