Re: REINDEX CONCURRENTLY 2.0

On 03/05/2017 07:56 PM, Robert Haas wrote:
> On Sat, Mar 4, 2017 at 12:34 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> I agree that'd it be nicer not to have this, but not having the feature at all is a lot worse than this wart.
>
> I, again, give that a firm "maybe". If the warts end up annoying 1%
> of the users who try to use this feature, then you're right. If they
> end up making a substantial percentage of people who try to use this
> feature give up on it, then we've added a bunch of complexity and
> future code maintenance for little real gain. I'm not ruling out the
> possibility that you're 100% correct, but I'm not nearly as convinced
> of that as you are.

I agree that these warts are annoying but I also think the limitations
can be explained pretty easily to users (e.g. by explaining it in the
manual how REINDEX CONCURRENTLY creates a new index to replace the old
one), and I think that is the important question about if a useful
feature with warts should be merged or not. Does it make things
substantially harder for the average user to grok?

And I would argue that his feature is useful for quite many, based on my
experience running a semi-large database. Index bloat happens and
without REINDEX CONCURRENTLY it can be really annoying to solve,
especially for primary keys. Certainly more people have problems with
index bloat than the number of people who store index oids in their
database.

Andreas