Peter Eisentraut <peter_e@gmx.net> writes:
> On 12/8/14 12:39 PM, Robert Haas wrote:
>> On Sun, Dec 7, 2014 at 9:54 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>> My radical proposal therefore would have been to embrace this
>>> inconsistency and get rid of PGC_BACKEND and PGC_SU_BACKEND altogether,
>>> relying on users interpreting the parameter names to indicate that
>>> changing them later may or may not have an effect. Unfortunately, the
>>> concerns about ignore_system_indexes prevent that.
>> What exactly are those concerns? Do you have a link to previous discussion?
> Earlier in the thread:
> http://www.postgresql.org/message-id/20108.1415120322@sss.pgh.pa.us
The core of the mentioned issues is that catalog searches done via the
systable_beginscan/systable_getnext API will ordinarily visit catalog
entries in the order of the specified index. However, if
ignore_system_indexes is set, you get a seqscan that will return the same
tuples in heap order (effectively, random order). There are known cases
where this results in minor planner inefficiencies, and I'm worried that
there might be outright bugs we don't know about, since that whole
operating mode can be best be described as entirely untested outside of
the bootstrap sequence.
Barring someone committing to spend the time to improve that situation
(time that would be poorly invested IMO), I don't think that we want to
open up ignore_system_indexes as USERSET, or do anything else to encourage
its use.
If we're intent on removing PGC_BACKEND then I'd be okay with
reclassifying ignore_system_indexes as SUSET; but I'm not exactly
convinced that we should be trying to get rid of PGC_BACKEND.
regards, tom lane
