Re: Proposal to Enable/Disable Index using ALTER INDEX
От | Sami Imseih |
---|---|
Тема | Re: Proposal to Enable/Disable Index using ALTER INDEX |
Дата | |
Msg-id | CAA5RZ0vLEAX_qR4J7iqK-ZVdjvobEH8xcdrtBC+6rmNKRHr8qg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal to Enable/Disable Index using ALTER INDEX ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | pgsql-hackers |
> Unless someone is willing to try and get “The PostgreSQL team’s blessed guide to index management” > into the documentation I really doubt we can agree on one set of index management guidelines. If anything, this thread has proven there are many ways to bake this cake :) and all approaches have merit. > we should probably just accept this will be a bit tool belt approach and > there will be tools that for one person’s approach are not useful. +1 > but I just don't feel comfortable > being the committer/forever-owner of having a GUC that overwrites > something that's explicitly written in the system catalogue tables > that is disabled. That's fair > Other committers might feel differently, so if the general consensus > is ALTER TABLE+GUC, then I'll leave it to them. I'm by no means saying > this to try and influence the discussion here. If the ALTER TABLE > alone is not seen as useful If we only go with the ALTER, my concern is there is really no way an extension ( i.e. pg_hint_plan ) can even provide the behavior of this GUC. If the value is 'invisible' in the catalog, the index is no longer available to extensions via RelOptInfo->indexlist, and it cannot be forced to be considered for planning by the extension. So, unless we provide the GUC in-core, it will not be possible for it to be achieved by extensions. Maybe someone can prove me wrong here. -- Sami
В списке pgsql-hackers по дате отправления: