David Fetter da...@fetter.org 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
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
David Fetter da...@fetter.org 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
Jeff Davis pg...@j-davis.com 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
--On 20. Oktober 2009 10:49:33 -0700 David Fetter da...@fetter.org 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
In response to Bernd Helmle maili...@oopsware.de:
--On 20. Oktober 2009 10:49:33 -0700 David Fetter da...@fetter.org 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
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)
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
On Tue, 20 Oct 2009, Bernd Helmle wrote:
--On 20. Oktober 2009 10:49:33 -0700 David Fetter da...@fetter.org 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
David Fetter da...@fetter.org 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:
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
Josh Berkus j...@agliodbs.com 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
On 10/20/09 5:06 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
On Tue, Oct 20, 2009 at 1:49 PM, David Fetter da...@fetter.org 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
Robert Haas robertmh...@gmail.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
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
Marc G. Fournier scra...@hub.org 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
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
18 matches
Mail list logo
