Обсуждение: Going, going, GUCs!

Поиск
Список
Период
Сортировка

Going, going, GUCs!

От
David Fetter
Дата:
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


Re: Going, going, GUCs!

От
"Kevin Grittner"
Дата:
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


Re: Going, going, GUCs!

От
Jeff Davis
Дата:
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



Re: Going, going, GUCs!

От
Tom Lane
Дата:
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


Re: Going, going, GUCs!

От
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


Re: Going, going, GUCs!

От
Bernd Helmle
Дата:

--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


Re: Going, going, GUCs!

От
Bill Moran
Дата:
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/


Re: Going, going, GUCs!

От
Andrew Dunstan
Дата:

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




Re: Going, going, GUCs!

От
"Marc G. Fournier"
Дата:
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


Re: Going, going, GUCs!

От
"Marc G. Fournier"
Дата:
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


Re: Going, going, GUCs!

От
Tom Lane
Дата:
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


Re: Going, going, GUCs!

От
Josh Berkus
Дата:
> 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


Re: Going, going, GUCs!

От
Tom Lane
Дата:
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


Re: Going, going, GUCs!

От
Josh Berkus
Дата:
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


Re: Going, going, GUCs!

От
Robert Haas
Дата:
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


Re: Going, going, GUCs!

От
Itagaki Takahiro
Дата:
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




Re: Going, going, GUCs!

От
"Marc G. Fournier"
Дата:
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


Re: Going, going, GUCs!

От
Itagaki Takahiro
Дата:
"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




Re: Going, going, GUCs!

От
Greg Smith
Дата:
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