On Tue, Jan 26, 2021 at 6:59 PM Tomas Vondra <
tomas.vondra@enterprisedb.com> wrote:
>
>
>
> On 1/26/21 7:52 PM, John Naylor wrote:
> > On Fri, Jan 22, 2021 at 10:59 PM Tomas Vondra
> > <
tomas.vondra@enterprisedb.com <mailto:
tomas.vondra@enterprisedb.com>>
> > wrote:
> > > Hmm. I think Alvaro also mentioned he'd like to use this as a drop-in
> > > replacement for minmax (essentially, using these opclasses as the
> > > default ones, with the option to switch back to plain minmax). I'm not
> > > convinced we should do that - though. Imagine you have minmax indexes in
> > > your existing DB, it's working perfectly fine, and then we come and just
> > > silently change that during dump/restore. Is there some past example
> > > when we did something similar and it turned it to be OK?
> >
> > I was assuming pg_dump can be taught to insert explicit opclasses for
> > minmax indexes, so that upgrade would not cause surprises. If that's
> > true, only new indexes would have the different default opclass.
> >
>
> Maybe, I suppose we could do that. But I always found such changes
> happening silently in the background a bit suspicious, because it may be
> quite confusing. I certainly wouldn't expect such difference between
> creating a new index and index created by dump/restore. Did we do such
> changes in the past? That might be a precedent, but I don't recall any
> example ...
I couldn't think of a comparable example either. It comes down to evaluating risk. On the one hand it's nice if users get an enhancement without having to know about it, on the other hand if there is some kind of noticeable regression, that's bad.
--
John Naylor
EDB:
http://www.enterprisedb.com
