Re: Minmax indexes
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>,
Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-06-17T14:31:45Z
Lists: pgsql-hackers
On 2014-06-17 10:26:11 -0400, Robert Haas wrote: > On Sat, Jun 14, 2014 at 10:34 PM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: > > Robert Haas wrote: > >> On Wed, Sep 25, 2013 at 4:34 PM, Alvaro Herrera > >> <alvherre@2ndquadrant.com> wrote: > >> > Here's an updated version of this patch, with fixes to all the bugs > >> > reported so far. Thanks to Thom Brown, Jaime Casanova, Erik Rijkers and > >> > Amit Kapila for the reports. > >> > >> I'm not very happy with the use of a separate relation fork for > >> storing this data. > > > > Here's a new version of this patch. Now the revmap is not stored in a > > separate fork, but together with all the regular data, as explained > > elsewhere in the thread. > > Cool. > > Have you thought more about this comment from Heikki? > > http://www.postgresql.org/message-id/52495DD3.9010809@vmware.com Is there actually a significant usecase behind that wish or just a general demand for being generic? To me it seems fairly unlikely you'd end up with something useful by doing a minmax index over bounding boxes. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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