Re: Minmax indexes
Greg Stark <stark@mit.edu>
From: Greg Stark <stark@mit.edu>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Claudio Freire <klaussfreire@gmail.com>,
Heikki Linnakangas <hlinnakangas@vmware.com>,
Andres Freund <andres@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-07-09T23:35:42Z
Lists: pgsql-hackers
On Wed, Jul 9, 2014 at 10:16 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > there is no hardcoded assumption on the number of index > values stored per heap column, so it is possible to build an opclass > that stores a bounding box column for a geometry heap column, for > instance. I think the more Postgresy thing to do is to store one datum per heap column. It's up to the opclass to find or make a composite data type that stores all the necessary state. So you could make a minmax_accum data type like NumericAggState in numeric.c:numeric_accum() or the array of floats in float8_accum. For a bounding box a 2d geometric min/max index could use the "box" data type for example. The way you've done it seems more convenient but there's something to be said for using the same style for different areas. A single bounding box accumulator function would probably suffice for both an aggregate and index opclass for example. But this sounds pretty great. I think it would let me do the bloom filter index I had in mind fairly straightforwardly. The result would be something very similar to a bitmap index. I'm not sure if there's a generic term that includes bitmap indexes or other summary functions like bounding boxes (which min/max is basically -- a 1D bounding box). Thanks a lot for listening and being so open, I think what you describe is a lot more flexible than what you had before and I can see some pretty great things coming out of it (including min/max itself of course). -- greg
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