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
- test.sh (application/x-shellscript)
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
-
Refactor per-page logic common to all redo routines to a new function.
- f8f4227976a2 9.5.0 cited
-
Reduce use of heavyweight locking inside hash AM.
- 76837c1507cb 9.3.0 cited
-
Scan the buffer pool just once, not once per fork, during relation drop.
- ece01aae4792 9.2.0 cited
-
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
- 9e2a87b62db8 7.1.1 cited