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
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 |