Re: Invisible Indexes - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Invisible Indexes
Date
Msg-id CAH2-WznzTMYH4LE1o3uZNTKEghLU+W+dXbLv_sB+dDXabcRDcg@mail.gmail.com
Whole thread Raw
In response to Re: Invisible Indexes  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
On Wed, Jul 4, 2018 at 7:09 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> hmm. Maybe I missed any other use case.  The mention of hypothetical
> indexes seems a bit lost on this thread. Andrew's proposal mentions
> that an invisible index will just not be considered by the planner.
> I'd very much assume here that the index must exist on disk, and
> there's not much hypothetical about that.

+1

> Like Andrew, I'm not much of a fan of the GUC idea.  Testing a plan
> without an index could just be a BEGIN; ALTER INDEX; EXPLAIN;
> ROLLBACK; operation. It seems much neater not to spread the properties
> of an index all over the place when we have a perfectly good table to
> store index properties in.  Unsure why Tom thinks that's ugly.

I have to admit to not getting what's so ugly about it myself.

> FWIW I have also seen customers asking if they can test drop an index
> by setting indisready to false. Naturally, people are often a bit
> scared to confirm messing around with catalogue tables on a busy
> production server is fine.

That's very easy for me to understand. A large production application
can be complicated in a way that nobody can quite nail down. Often,
being sure that dropping an index won't have any ramifications is an
unobtainable luxury, because knowledge about how the app works isn't
centralized in one place. If it's a very large index, why even take a
very small chance?

-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Invisible Indexes
Next
From: Michael Paquier
Date:
Subject: Re: Old small commitfest items