Re: Minmax indexes
Jeff Janes <jeff.janes@gmail.com>
From: Jeff Janes <jeff.janes@gmail.com>
To: Jaime Casanova <jaime@2ndquadrant.com>
Cc: Josh Berkus <josh@agliodbs.com>,
Alvaro Herrera <alvherre@2ndquadrant.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:17:50Z
Lists: pgsql-hackers
On Thu, Jul 10, 2014 at 2:30 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote: > On Thu, Jul 10, 2014 at 3:50 PM, Josh Berkus <josh@agliodbs.com> wrote: > > On 07/10/2014 12:20 PM, Alvaro Herrera wrote: > >>> So I guess the only thing left is to issue a NOTICE when said alter > >>> > takes place (I don't see that on the patch, but maybe it's there?) > >> That's not in the patch. I don't think we have an appropriate place to > >> emit such a notice. > > > > What do you mean by "don't have an appropriate place"? > > > > The suggestion is that when a user does: > > > > ALTER INDEX foo_minmax SET PAGES_PER_RANGE=100 > > > > they should get a NOTICE: > > > > "NOTICE: changes to pages per range will not take effect until the index > > is REINDEXed" > > > > otherwise, we're going to get a lot of "I Altered the pages per range, > > but performance didn't change" emails. > > > > How is this different from "ALTER TABLE foo SET (FILLFACTOR=80); " or > from "ALTER TABLE foo ALTER bar SET STORAGE EXTERNAL; " ? > > we don't get a notice for these cases either > I think those are different. They don't rewrite existing data in the table, but they are applied to new (and updated) data. My understanding is that changing PAGES_PER_RANGE will have no effect on future data until a re-index is done, even if the entire table eventually turns over. Cheers, Jeff
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