Re: Proposal to Enable/Disable Index using ALTER INDEX - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Proposal to Enable/Disable Index using ALTER INDEX
Date
Msg-id 3b9b0463-4a86-4bbb-aa12-252748479f52@eisentraut.org
Whole thread Raw
In response to Re: Proposal to Enable/Disable Index using ALTER INDEX  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal to Enable/Disable Index using ALTER INDEX
List pgsql-hackers
On 24.09.24 20:21, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> On 23.09.24 22:51, Shayon Mukherjee wrote:
>>> I am happy to draft a patch for this as well. I think I have a working
>>> idea so far of where the necessary checks might go. However if you don’t
>>> mind, can you elaborate further on how the effect would be similar to
>>> enable_indexscan?
> 
>> Planner settings like enable_indexscan used to just add a large number
>> (disable_cost) to the estimated plan node costs.  It's a bit more
>> sophisticated in PG17.  But in any case, I imagine "disabling an index"
>> could use the same mechanism.  Or maybe not, maybe the setting would
>> just completely ignore the index.
> 
> 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.




pgsql-hackers by date:

Previous
From: Andrei Zubkov
Date:
Subject: Re: Vacuum statistics
Next
From: Peter Eisentraut
Date:
Subject: Re: System views for versions reporting