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

From Vinícius Abrahão
Subject Re: Proposal to Enable/Disable Index using ALTER INDEX
Date
Msg-id CAM9Bfty9tqk9KZRNV2qGhYac-A8GoA6RgFb5TB9CpheNtEGDfQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal to Enable/Disable Index using ALTER INDEX  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Proposal to Enable/Disable Index using ALTER INDEX
List pgsql-hackers
On Wed, Oct 9, 2024 at 1:41 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Oct 9, 2024 at 4:19 AM David Rowley <dgrowleyml@gmail.com> wrote:
> On Wed, 9 Oct 2024 at 20:07, Shayon Mukherjee <shayonj@gmail.com> wrote:
> > [thinking…] Unless - we try to do support both a GUC and the ALTER INDEX ENABLE/DISABLE grammar + isdisabled attribute on pg_index?
>
> I just wanted to explain my point of view on this.  This is my opinion
> and is by no means authoritative.
>
> I was interested in this patch when you proposed it as an ALTER INDEX
> option. I know other committers seem interested, but I personally
> don't have any interest in the GUC option.  I think the reason I
> dislike it is that it's yet another not even half-baked take on
> planner hints (the other one being enable* GUCs). I often thought that
> if we ever did planner hints that it would be great to have multiple
> ways to specify the hints. Ordinarily, I'd expect some special comment
> type as the primary method to specify hints, but equally, it would be
> nice to be able to specify them in other ways. e.g. a GUC to have them
> apply to more than just 1 query. Useful for things such as "don't use
> index X".

+1. A GUC can be done as a contrib module using existing hooks, and I
think that's already been done outside of core, perhaps multiple
times. That certainly doesn't mean we CAN'T add it as an in-core
feature, but I do think "yet another not even half-baked take on
planner hints" is a fair description. What I would personally like to
see is for us to ship one or possibly more than one contrib module
that let people do hint-like things in useful ways, and this could be
a part of that. But I think we need better infrastructure for
controlling the planner behavior first, hence the "allowing extensions
to control planner behavior" thread.


What's the strategy here in this discussion? 
This topic is older than PostgreSQL itself - everytime WE talk about so-called "hints" we see procrastination in the name of trademarks.
Lack of definition of what can and can't be done with hooks and what is the infra-estructural code that is necessary to allow it from core.

Take for example the need of disabling an index. What does it mean practically and for which component of the code?
You are going to disable the index but not the update of it? Why? Does it imply that when you are going to re-enable it you are going to recreate it?
So that's more observed from the point of syntax and facilities. 
Also distributed into partitions and why not the opposite: the creation of a global index for all partitions. Also in discussion elsewhere.
Otherwise it will appear that people will need hints and contribs to "outsource" the main role of what is strategic to the team to companies elsewhere.

Regards,
Vinícius


 

pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)
Next
From: Shayon Mukherjee
Date:
Subject: Re: Proposal to Enable/Disable Index using ALTER INDEX