Re: [HACKERS] Going, going, GUCs!
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 gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
"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, 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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. FournierHub.Org Hosting Solutions S.A. scra...@hub.org http://www.hub.org Yahoo:yscrappySkype: hub.orgICQ:7615664MSN:scra...@hub.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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) > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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 these changes in alpha2? I wasn't > intending to be that quick off the mark... No, no, alpha3. Hence "try to remember" ... --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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 that quick off the mark... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
> 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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 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. FournierHub.Org Hosting Solutions S.A. scra...@hub.org http://www.hub.org Yahoo:yscrappySkype: hub.orgICQ:7615664MSN:scra...@hub.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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 http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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. FournierHub.Org Hosting Solutions S.A. scra...@hub.org http://www.hub.org Yahoo:yscrappySkype: hub.orgICQ:7615664MSN:scra...@hub.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
--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 was introduced due to performance complaints on some platforms which can't easily be resolved? -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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) > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Going, going, GUCs!
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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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