Re: Minmax indexes
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Greg Stark <stark@mit.edu>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>,
Andres Freund <andres@2ndquadrant.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-06-23T19:34:25Z
Lists: pgsql-hackers
On Thu, Jun 19, 2014 at 12:32 PM, Greg Stark <stark@mit.edu> wrote: > On Wed, Jun 18, 2014 at 4:51 AM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> Implementing something is a good way to demonstrate how it would look like. >> But no, I don't insist on implementing every possible design whenever a new >> feature is proposed. >> >> I liked Greg's sketch of what the opclass support functions would be. It >> doesn't seem significantly more complicated than what's in the patch now. > > As a counter-point to my own point there will be nothing stopping us > in the future from generalizing things. Dealing with catalogs is > mostly book-keeping headaches and careful work. it's something that > might be well-suited for a GSOC or first patch from someone looking to > familiarize themselves with the system architecture. It's hard to > invent a whole new underlying infrastructure at the same time as > dealing with all that book-keeping and it's hard for someone > familiarizing themselves with the system to also have a great new > idea. Having tasks like this that are easy to explain and that mentor > understands well can be easier to manage than tasks where the newcomer > has some radical new idea. Generalizing this in the future would be highly likely to change the on-disk format for existing indexes, which would be a problem for pg_upgrade. I think we will likely be stuck with whatever the initial on-disk format looks like for a very long time, which is why I think we need to try rather hard to get this right the first time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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