Re: Invisible Indexes

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Invisible Indexes
Date: 2018-07-05 02:38:51
Message-ID: CAH2-WznzTMYH4LE1o3uZNTKEghLU+W+dXbLv_sB+dDXabcRDcg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 4, 2018 at 7:09 PM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-07-05 02:53:52 Re: Old small commitfest items
Previous Message David Rowley 2018-07-05 02:09:46 Re: Invisible Indexes