> 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
