Re: Minmax indexes
Greg Stark <stark@mit.edu>
From: Greg Stark <stark@mit.edu>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Josh Berkus <josh@agliodbs.com>, 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-10T22:29:17Z
Lists: pgsql-hackers
On Thu, Jul 10, 2014 at 10:29 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > What I think should happen is that if the value is changed, the index > sholud be rebuilt right there. I disagree. It would be a non-orthogonal interface if ALTER TABLE sometimes causes the index to be rebuilt and sometimes just makes a configuration change. I already see a lot of user confusion when some ALTER TABLE commands rewrite the table and some are quick meta data changes. Especially in this case where the type of configuration being changed is just an internal storage parameter and the user visible shape of the index is unchanged it would be weird to rebuild the index. IMHO the "right" thing to do is just to say this parameter is read-only and have the AM throw an error when the user changes it. But even that would require an AM callback for the AM to even know about the change. -- 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