> 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
