В письме от 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.

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.

PS sorry I did not add mail list to the CC, so I send it second time...


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to