Nikolay Shaplov wrote:
> В письме от 27 мая 2016 15:05:58 Вы написали:
> > Nikolay Shaplov wrote:
> > > Story start from the point that I found out that a.m. can not forbid
> > > changing some of it's reloptions with ALTER INDEX command. That was not
> > > necessary before, because all reloptions at that existed at that time can
> > > be changed on fly. But now for bloom index it is unacceptable, because
> > > for changing bloom's reloptions for existing index will lead to index
> > > malfunction.
> >
> > Hmm, this sounds like a bug to me. In BRIN, if you change the
> > pages_per_range option for an existing index, the current index
> > continues to work because the value used during the last index build is
> > stored in the metapage. Only when you reindex after changing the option
> > the new value takes effect.
> >
> > I think Bloom should do likewise.
>
> I do not think that it is the best behavior. Because if we came to this
> situation, the current value of pages_per_range that index actually using is
> not available for user, because he is not able to look into meta page.
You're right in that, but this is a much less serious behavior than
causing the index to fail to work altogether just because the option was
changed. Since we're certainly not going to rework reloptions in 9.6,
IMO the bloom behavior should be changed to match BRIN's.
> In this case it would be better either forbid changing the options, so it
> would be consistent, or force index rebuild, then it would be consistent too.
> I would vote for first behavior as this is less work to do for me, and can be
> changed later, if it is really needed for some case.
I think forcing index rebuild is not a great idea. That turns a simple
ALTER INDEX command which doesn't block the index heavily nor for a long
time, into a much more serious deal.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
