Re: Invisible Indexes

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Invisible Indexes
Date: 2018-06-18 22:17:10
Message-ID: 05ec660b-6625-2e92-a5b6-b9229bc41e40@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/18/2018 06:12 PM, Tom Lane wrote:
> Peter Geoghegan <pg(at)bowt(dot)ie> writes:
>> On Mon, Jun 18, 2018 at 2:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I think the actually desirable way to handle this sort of thing is through
>>> an "index advisor" sort of plugin, which can hide a given index from the
>>> planner without any globally visible side-effects.
>> The globally visible side-effects are the point, though. Some users
>> desire cheap insurance against dropping what turns out to be the wrong
>> index.
> Perhaps there are use-cases where you want globally visible effects,
> but the primary use-case Andrew cited (i.e. EXPLAIN experimentation)
> would not want that.
>
> Anyway, if we do it with a GUC, the user can control the scope of
> the effects.
>
>

Yeah, but Peter makes the case that people want it for global
experimentation. "We think we can safely drop this humungous index that
would take us days to rebuild, but before we do let's make it invisible
and run for a few days just to make sure." I guess we could do that with
a GUC, but it seems ugly.

To Andres' point about the fragility of pg_index, maybe we'd need a
separate_catalog (pg_invisible_index)?

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-06-18 22:20:39 Re: Invisible Indexes
Previous Message Peter Geoghegan 2018-06-18 22:16:38 Re: Invisible Indexes