Re: [PATCH] Proposal to Enable/Disable Index using ALTER INDEX

> > > it will still be extremely risky in
> > > heavy production workloads. In short, we're both walking a bull
> > > through the china shop, but it would seem mine is much more
> > > temperamental than yours.
> >
> > Robert, Could you describe the GUC you would like to see?
> >
> > Also, I'd like to ask. what would be the argument against offering both options,
> > ALTER and a GUC to override the catalog, as currently proposed in the patch?
> >
> > This conversation has been mainly GUC is better than ALTER, or vice versa.
> >
> > It is clear, at least to me, there are merits in both approaches, so
> > what would be
> > the argument against making both options available ( maybe with a GUC that
> > could be more useful than a simple boolean )?
> >
>
> Just to reiterate, I am not against having both a GUC and ALTER
> option, if implemented correctly.

Thanks. This got lost, at least to me, in the thread above.

> Like David, I don't have good
> feelings about the ALTER / use_invisible_index GUC overwriting
> behavior that is explicitly written in the catalog,

OK, although I don't necessarily think this is something to be frowned
upon. I mean, if we end up with an ALTER/GUC combo, I can't see
how we can avoid such behavior.

> and I see no
> reason to settle for a technically awkward solution when I think it
> also delivers a poor user interface that will be hard to reason about
> and/or debug in production.

This is already an established pattern has been used by other
RDBMS's. Having worked with such interface in the past, a combo of
ALTER and GUC, I never thought it was awkward and it's quite simple to
understand/maintain. But that is subjective.

> So I think the "right" interface looks something like a GUC that would
> be something like "ignore_index_planning" which takes a csv list of
> index names that the planner would ignore.

A few years back, I explored this idea, and I did not really like the parsing
overhead for every execution. You will need to supply a list of fully-qualified
( dbname.schemaname.indexname) names or carefully manage the GUC
per database. Also, if you drop an index, you now must go cleanup the list,
and especially if at some point you recreate the index with the same name.
There is also that you have to push this GUC to all your standbys manually.

This never sounded good to me as a core feature, or do I think it's a really
friendly interface, and I think you can get in more trouble trying to deal with
such a GUC that requires such management.

--
Sami