Re: Proposal to Enable/Disable Index using ALTER INDEX

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Shayon Mukherjee <shayonj(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Proposal to Enable/Disable Index using ALTER INDEX
Date: 2024-10-16 12:54:02
Message-ID: CA+TgmoZweRq4A9xBY-+n1OPDt76Vf2h3sVvLdbZNuzp68S+m4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 16, 2024 at 8:33 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> > Yeah, I'd be inclined to implement this by having create_index_paths
> > just not make any paths for rejected indexes. Or you could back up
> > another step and keep plancat.c from building IndexOptInfos for them.
> > The latter might have additional effects, such as preventing the plan
> > from relying on a uniqueness condition enforced by the index. Not
> > clear to me if that's desirable or not.
>
> Yes, I think you'd want that, because one of the purposes of this
> feature would be to test whether it's okay to drop an index. So you
> don't want the planner to take any account of the index for its decisions.

I think this is right. I think we want to avoid invalidating the
index, so we still need to consider it in determining where HOT
updates must be performed, but we don't want to "improve" the plan
using the index if it's disabled.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2024-10-16 13:31:58 Re: System views for versions reporting
Previous Message Peter Eisentraut 2024-10-16 12:47:34 Re: System views for versions reporting