Re: Minmax indexes
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Vik Fearing <vik.fearing@dalibo.com>
Cc: Andres Freund <andres@2ndquadrant.com>,
Heikki Linnakangas <hlinnakangas@vmware.com>,
Robert Haas <robertmhaas@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-06-19T13:43:06Z
Lists: pgsql-hackers
Vik Fearing <vik.fearing@dalibo.com> writes: > On 06/18/2014 12:46 PM, Andres Freund wrote: >> So to implement a feature one now has to implement the most generic >> variant as a prototype first? Really? > Well, there is the inventor's paradox to consider. I have not seen anyone demanding a different implementation in this thread. What *has* been asked for, and not supplied, is a concrete defense of the particular level of generality that's been selected in this implementation. It's not at all clear to the rest of us whether it was the right choice, and that is something that ought to be asked now not later. regards, tom lane
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