Re: Going, going, GUCs!

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> We just had a conversation about whether or not to massively break
> backward compatibility. The consensus was, as I'm sure you are aware,
> was "no".

We should not discuss serveral kinds of parameters at once.

1. Options for backward compatibility with old PostgreSQL
2. Options for compatibility with other DBMSs and applications
3. Useless parameters
4. Parameters for DBAs who are paranoid about performance
5. Still used

I agree we should not drop 1, 2 and 5,
but we can drop 3 and some portion of 4.

In addition, it might be good idea to hide some parameters
from the default postgresql.conf in order to simplify it,
even though we will still have those knobs.

----
1. Options for backward compatibility with old PostgreSQL:
> > add_missing_from (should be off)
> > array_nulls (should be on)
> > default_with_oids (should be off)
> > regex_flavor (should be advanced, regex flavor can be controlled on a per-regex basis when they're advanced)
> > sql_inheritance (should be on)
> > password_encryption (should be on)

2. Options for compatibility with other DBMSs and applications:
> > standard_conforming_strings (should be on)
> > transform_null_equals (should probably be off)

3. Useless parameters:
> > commit_delay (no need for this knob)
> > commit_siblings (no need for this knob)

4. Parameters for DBAs who are paranoid about performance:
> > track_activities (should be on)
> > track_counts (should be on)
> > update_process_title (should be on)

5. Still used:
> > synchronize_seqscans (should be on) -- used by pg_dump

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center