Re: Minmax indexes
Greg Stark <stark@mit.edu>
From: Greg Stark <stark@mit.edu>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Andres Freund <andres@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-06-19T16:32:18Z
Lists: pgsql-hackers
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. -- 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