On Tue, 20 Oct 2009, David Fetter wrote:
commit_delay (no need for this knob)
commit_siblings (no need for this knob)
Both these knobs do something that's valuable sometimes: help group
commits into bigger chunks when there are lots of active clients. I've
watched it help a bit on heavy wr
"Marc G. Fournier" wrote:
> > 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.
>
> That might be an idea for anything that is meant to be 'deprecated' in the
> first place,
On Wed, 21 Oct 2009, Itagaki Takahiro wrote:
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.
That might be an idea for anything that is meant to be 'deprecated' in the
first place
Robert Haas 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
On Tue, Oct 20, 2009 at 1:49 PM, David Fetter wrote:
> Folks,
>
> I'd like to see about removing the following GUCs:
>
> add_missing_from (should be off)
> array_nulls (should be on)
> commit_delay (no need for this knob)
> commit_siblings (no need for this knob)
> default_with_oids (should be off
On 10/20/09 5:06 PM, Tom Lane wrote:
> Josh Berkus writes:
>>> Meanwhile, last chance for anyone to object to killing these two?
>
>> Nope. People will have to fix their apps, but it's about time. I'll
>> try to remember to advertise the breakage ...
>
> Hmm, did you want to try to include the
Josh Berkus writes:
>> Meanwhile, last chance for anyone to object to killing these two?
> Nope. People will have to fix their apps, but it's about time. I'll
> try to remember to advertise the breakage ...
Hmm, did you want to try to include these changes in alpha2? I wasn't
intending to be
> Meanwhile, last chance for anyone to object to killing these two?
Nope. People will have to fix their apps, but it's about time. I'll
try to remember to advertise the breakage ...
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
David Fetter writes:
> add_missing_from (should be off)
> regex_flavor (should be advanced, regex flavor can be controlled on a
> per-regex basis when they're advanced)
I believe that we do have consensus on removing those two, based on
discussions here and here respectively:
http://archives.pos
On Tue, 20 Oct 2009, Bernd Helmle wrote:
--On 20. Oktober 2009 10:49:33 -0700 David Fetter wrote:
track_activities (should be on)
track_counts (should be on)
update_process_title (should be on)
Removing all track* GUCs would only make sense if we are going to make
autovacuum mandatory, i
Why? Are they causing problems leaving them there? What sorts of
problems will arise by *removing* them? I know with OACS,
add_missing_from is required right now, but that code *should* be fixable,
and there is an overwhelming reason from an advancement perspective to
having it removed (ie
David Fetter wrote:
Folks,
I'd like to see about removing the following GUCs:
add_missing_from (should be off)
array_nulls (should be on)
commit_delay (no need for this knob)
commit_siblings (no need for this knob)
default_with_oids (should be off)
password_encryption (should be on)
regex_fla
In response to Bernd Helmle :
>
>
> --On 20. Oktober 2009 10:49:33 -0700 David Fetter wrote:
>
> > track_activities (should be on)
> > track_counts (should be on)
> > update_process_title (should be on)
I'm not replying in the correct part of the thread, but I just happened
to notice this by a
--On 20. Oktober 2009 10:49:33 -0700 David Fetter wrote:
track_activities (should be on)
track_counts (should be on)
update_process_title (should be on)
Removing all track* GUCs would only make sense if we are going to make
autovacuum mandatory, i think. And i thought update_process_title
Jeff Davis writes:
> On Tue, 2009-10-20 at 10:49 -0700, David Fetter wrote:
>> synchronize_seqscans (should be on)
> Right now this is used for pg_dump, because pg_dump could un-cluster a
> previously clustered table (I believe Greg Stark made this observation).
In general, the setting results i
David Fetter writes:
> I'd like to see about removing the following GUCs:
> add_missing_from (should be off)
> array_nulls (should be on)
> commit_delay (no need for this knob)
> commit_siblings (no need for this knob)
> default_with_oids (should be off)
> password_encryption (should be on)
> reg
On Tue, 2009-10-20 at 10:49 -0700, David Fetter wrote:
> synchronize_seqscans (should be on)
Right now this is used for pg_dump, because pg_dump could un-cluster a
previously clustered table (I believe Greg Stark made this observation).
This is actually a stats/planner issue more than anything els
David Fetter wrote:
> I'd like to see about removing the following GUCs:
> sql_inheritance (should be on)
I'd rather see that stay, so that I can make sure it's off. That
said, we have other ways to enforce shop policy on this, if need be.
> track_counts (should be on)
I believe we foun
Folks,
I'd like to see about removing the following GUCs:
add_missing_from (should be off)
array_nulls (should be on)
commit_delay (no need for this knob)
commit_siblings (no need for this knob)
default_with_oids (should be off)
password_encryption (should be on)
regex_flavor (should be advanced,
19 matches
Mail list logo