Обсуждение: Going, going, GUCs!
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, regex flavor can be controlled on a per-regex basis when they're advanced) sql_inheritance (should be on) standard_conforming_strings (should be on) synchronize_seqscans (should be on) track_activities (should be on) track_counts (should be on) transform_null_equals (should probably be off) update_process_title (should be on) What say on each? When? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@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 believe we found a slight performance benefit to turning this off for bulk loads (during which we also turn off autovacuum). We finish the process by running VACUUM FREEZE ANALYZE on the database and restoring the normal postgresql.conf file (with these on). A minimal hit on bulk load operations wouldn't be the end of the world, but I'd rather avoid it. > transform_null_equals (should probably be off) If we're eliminating the GUC, it *better* be treated as off; otherwise a lot of code written to the SQL specification will be broken. The others don't matter much to me, personally; but I wonder why you are pushing this in the face of the concurrent threads, where the consensus seems to be that there is not much to be gained by eliminating these, and risk of problems. What makes the GUCs on you list worth expending the effort? (I'd say that each one merits separate justification.) -Kevin
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 else, because the table isn't _really_ unclustered, but it is still an issue (seems minor to me, but not insignificant). Also, it seems reasonable that testers might want to use something like this, if they don't want to ORDER BY. For instance, if testing postgresql itself, ORDER BY would change what you're testing. Regards,Jeff Davis
David Fetter <david@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 on)
> regex_flavor (should be advanced, regex flavor can be controlled on a per-regex basis when they're advanced)
> sql_inheritance (should be on)
> standard_conforming_strings (should be on)
> synchronize_seqscans (should be on)
> track_activities (should be on)
> track_counts (should be on)
> transform_null_equals (should probably be off)
> update_process_title (should be on)
There was consensus on removing about two of these. Back off.
regards, tom lane
Jeff Davis <pgsql@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 setting results in producing indeterminate output where
previous versions produced deterministic results; we did get complaints
about that when it came out. Furthermore the performance gain may be
marginal or nonexistent depending on your application. The code savings
from removing the setting would certainly be marginal or nonexistent.
I can't see a good argument for taking this out.
regards, tom lane
--On 20. Oktober 2009 10:49:33 -0700 David Fetter <david@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 update_process_title was introduced due to performance complaints on some platforms which can't easily be resolved? -- Thanks Bernd
In response to Bernd Helmle <mailings@oopsware.de>: > > > --On 20. Oktober 2009 10:49:33 -0700 David Fetter <david@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 happened to notice this by accident. update_process_title is a known performance killer on FreeBSD (unless this has been fixed in 8.x). As a result, it would hurt me if that were removed. I always have it turned off. Even if the performance problem is fixed in FreeBSD 8.x, this should be left in for a few more releases until newer versions of FreeBSD are the standard. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/
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_flavor (should be advanced, regex flavor can be controlled on a per-regex basis when they're advanced) > sql_inheritance (should be on) > standard_conforming_strings (should be on) > synchronize_seqscans (should be on) > track_activities (should be on) > track_counts (should be on) > transform_null_equals (should probably be off) > update_process_title (should be on) > > What say on each? When? > > > We don't do wholesale changes like this. If you have a case to make then make it for each one individually. I will observe, however, that removing standard_conforming_strings and making it always on will break thousands and thousands of apps. cheers andrew
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. new code that Tom is developing), but what about the rest ... ? On Tue, 20 Oct 2009, 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_flavor (should be advanced, regex flavor can be controlled on a per-regex basis when they're advanced) > sql_inheritance (should be on) > standard_conforming_strings (should be on) > synchronize_seqscans (should be on) > track_activities (should be on) > track_counts (should be on) > transform_null_equals (should probably be off) > update_process_title (should be on) > > What say on each? When? > > Cheers, > David. > -- > David Fetter <david@fetter.org> http://fetter.org/ > Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter > Skype: davidfetter XMPP: david.fetter@gmail.com > > Remember to vote! > Consider donating to Postgres: http://www.postgresql.org/about/donate > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > ---- Marc G. Fournier Hub.Org Hosting Solutions S.A. scrappy@hub.org http://www.hub.org Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org
On Tue, 20 Oct 2009, Bernd Helmle wrote: > > > --On 20. Oktober 2009 10:49:33 -0700 David Fetter <david@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 update_process_title was > introduced due to performance complaints on some platforms which can't easily > be resolved? Yes, update_process_title on FreeBSD defaults to 'off' as the overhead based on how FreeBSD does the update was enough to make a noticeable difference in performance ... suspect that is the same for all the *BSDs, not sure about any other platform though ... maybe Windows? ---- Marc G. Fournier Hub.Org Hosting Solutions S.A. scrappy@hub.org http://www.hub.org Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org
David Fetter <david@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: http://archives.postgresql.org/pgsql-hackers/2009-10/msg00958.php http://archives.postgresql.org/pgsql-hackers/2009-10/msg00807.php Each of those threads established that there was a nontrivial identifiable benefit to removing the particular option, not just that somebody thought it was useless. I think the rest of the list needs to be held to a similar standard before removing anything. Meanwhile, last chance for anyone to object to killing these two? regards, tom lane
> 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
Josh Berkus <josh@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
intending to be that quick off the mark...
regards, tom lane
On 10/20/09 5:06 PM, Tom Lane wrote: > Josh Berkus <josh@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 > intending to be that quick off the mark... No, no, alpha3. Hence "try to remember" ... --Josh
On Tue, Oct 20, 2009 at 1:49 PM, David Fetter <david@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 (should be off) > password_encryption (should be on) > regex_flavor (should be advanced, regex flavor can be controlled on a per-regex basis when they're advanced) > sql_inheritance (should be on) > standard_conforming_strings (should be on) > synchronize_seqscans (should be on) > track_activities (should be on) > track_counts (should be on) > transform_null_equals (should probably be off) > update_process_title (should be on) > > What say on each? When? 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". So why bring it up again, and with absolutely zero justification for the proposed changes? Each and every knob on this list was added for some reason, and we should remove it when, and only when, that reason either no longer applies, or there is some countervailing reason. ...Robert
Robert Haas <robertmhaas@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 old PostgreSQL 2. Options for compatibility with other DBMSs and applications3. 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
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, maybe? Document it in the docs, but dont including it in the default postgresql.conf? ---- Marc G. Fournier Hub.Org Hosting Solutions S.A. scrappy@hub.org http://www.hub.org Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org
"Marc G. Fournier" <scrappy@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 place, maybe? Document it in the docs, but dont including it in the > default postgresql.conf? It was just an idea for step-by-step deprecation. I didn't intended to do so for all parameters, but some of them, like default_with_oids, would fit in the way because users should not use it but pg_dump can still use it. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
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 writes at a client site before, and some of the Sun benchmarks that have been published got a little boost out of it too in a similar situation. The use case for both is pretty narrow, and isn't actually the same one the feature was intended to fix (originally this was supposed to be useful more for the person who can't commit very fast at all; it isn't). But there is some value, and the code involved is pretty small, not much beyond the GUC overhead. I'd like to get both pruned out in favor of a better chunking write implementation that's aimed squarely at the problem these two help on accidentally. Until that point, it's hard to justify wiping them out when they do have some value and little code overhead to keep around. As a comment on one of the larger themes brought up in this thread, I don't think picking off a few parameters is of any value to making the postgresql.conf file easier to work with. That needs a much larger pruning before moving in that direction is actually going to help anyone. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD