Thread: Fractions in GUC variables

Fractions in GUC variables

From
John Gorman
Date:

This patch implements the first wiki/Todo Configuration Files item "Consider normalizing fractions in postgresql.conf, perhaps using '%'".

The "Fractions in GUC variables" discussion is here.


This patch implements expressing GUC variables as percents in postgresql.conf.

autovacuum_vacuum_scale_factor = 20%   # percent of table size before vacuum
autovacuum_analyze_scale_factor = 10%  # percent of table size before analyze

As you can see the postgresql.conf file and the documentation read more naturally.  I added a regression test to guc.sql. The sql interface also accepts both numeric and percent forms although the percent form must be quoted because '%' is an operator.

show cursor_tuple_fraction; --> 10%
set cursor_tuple_fraction = .15; --> 15%
set cursor_tuple_fraction = '33%'; --> 33%

I tagged four configuration variables to display as percents.

The attached patch applies cleanly against master and passes all regression tests including two new tests in guc.sql.

Attachment

Re: Fractions in GUC variables

From
Josh Berkus
Date:
On 12/07/2014 11:48 AM, John Gorman wrote:
> 
> This patch implements the first wiki/Todo Configuration Files item
> "Consider normalizing fractions in postgresql.conf, perhaps using '%'".
> 
> The "Fractions in GUC variables" discussion is here.
> 

Oh, this is nice!  Thanks for working on it.


-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



Re: Fractions in GUC variables

From
Michael Paquier
Date:
On Mon, Dec 8, 2014 at 4:48 AM, John Gorman <johngorman2@gmail.com> wrote:
> The attached patch applies cleanly against master and passes all regression
> tests including two new tests in guc.sql.
Please be sure to register your patch to the upcoming commit fest,
this way it will not fall into oblivion and will get some feedback:
https://commitfest.postgresql.org/action/commitfest_view?id=25
-- 
Michael



Re: Fractions in GUC variables

From
Heikki Linnakangas
Date:
On 12/07/2014 09:48 PM, John Gorman wrote:
> This patch implements the first wiki/Todo Configuration Files item
> "Consider normalizing fractions in postgresql.conf, perhaps using '%'".
>
> The "Fractions in GUC variables" discussion is here.
>
> http://www.postgresql.org/message-id/467132CF.9020501@enterprisedb.com

Ah, flash from the past :-). Thanks for looking into this.

The bgwriter_lru_percent and bgwriter_all_percent settings are gone now, 
so the original reason to do this is gone. We consistently use fractions 
in the GUCs now.

> This patch implements expressing GUC variables as percents in
> postgresql.conf.
>
> autovacuum_vacuum_scale_factor = 20%   # percent of table size before vacuum
> autovacuum_analyze_scale_factor = 10%  # percent of table size before
> analyze
>
> As you can see the postgresql.conf file and the documentation read more
> naturally.  I added a regression test to guc.sql. The sql interface also
> accepts both numeric and percent forms although the percent form must be
> quoted because '%' is an operator.
>
> show cursor_tuple_fraction; --> 10%
> set cursor_tuple_fraction = .15; --> 15%
> set cursor_tuple_fraction = '33%'; --> 33%
>
> I tagged four configuration variables to display as percents.

I'm not sure I agree that percentages are better than fractions. I'd 
vote a -0.5 for changing the default display format. There isn't much 
harm in accepting them as a secondary format, though.

We should only accept percentages for settings where that makes sense. 
It is sensible for most of the PGC_REAL settings, but not so much for 
geqo_selection_bias or seed, for example.

Overall, I feel that this isn't really worth the trouble. We use 
fractions consistently now, so there isn't much room for confusion over 
what the current values mean. Using a percentage might be more familiar 
for some people, but OTOH you'll have to get used to the fractions 
anyway, unless we change the default output format too, and I'm not in 
favour of doing that. I suggest that we just drop this, and remove the 
TODO item.

- Heikki




Re: Fractions in GUC variables

From
Peter Eisentraut
Date:
On 12/15/14 8:56 AM, Heikki Linnakangas wrote:
>> show cursor_tuple_fraction; --> 10%
>> set cursor_tuple_fraction = .15; --> 15%
>> set cursor_tuple_fraction = '33%'; --> 33%
>>
>> I tagged four configuration variables to display as percents.
> 
> I'm not sure I agree that percentages are better than fractions. I'd
> vote a -0.5 for changing the default display format. There isn't much
> harm in accepting them as a secondary format, though.

Agreed with not changing the default output.  Everyone is used to it,
and there is no reason why the percent output would be intrinsically better.

> We should only accept percentages for settings where that makes sense.
> It is sensible for most of the PGC_REAL settings, but not so much for
> geqo_selection_bias or seed, for example.

Right.  But then this feature would get more complicated, as opposed to
supposedly making things simpler.

> Overall, I feel that this isn't really worth the trouble. We use
> fractions consistently now, so there isn't much room for confusion over
> what the current values mean. Using a percentage might be more familiar
> for some people, but OTOH you'll have to get used to the fractions
> anyway, unless we change the default output format too, and I'm not in
> favour of doing that. I suggest that we just drop this, and remove the
> TODO item.

Agreed.

The patch is sound as far as it goes (I might be inclined to accept
whitespace between number and % sign), but given the above points and
the original reason for it having been eliminated, I'm inclined to drop it.



Re: Fractions in GUC variables

From
Bruce Momjian
Date:
On Mon, Dec 15, 2014 at 10:19:19AM -0500, Peter Eisentraut wrote:
> > Overall, I feel that this isn't really worth the trouble. We use
> > fractions consistently now, so there isn't much room for confusion over
> > what the current values mean. Using a percentage might be more familiar
> > for some people, but OTOH you'll have to get used to the fractions
> > anyway, unless we change the default output format too, and I'm not in
> > favour of doing that. I suggest that we just drop this, and remove the
> > TODO item.
> 
> Agreed.
> 
> The patch is sound as far as it goes (I might be inclined to accept
> whitespace between number and % sign), but given the above points and
> the original reason for it having been eliminated, I'm inclined to drop it.

TODO item removed.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



Re: Fractions in GUC variables

From
Jim Nasby
Date:
On 12/7/14, 1:48 PM, John Gorman wrote:
> This patch implements the first wiki/Todo Configuration Files item "Consider normalizing fractions in
postgresql.conf,perhaps using '%'".
 

FWIW, I've reviewed this (should have read the thread first :/). It looks clean, passes make check and works as
advertised.I also looked at what config options were set to be % and they make sense. Looking for .[0-9] in
postgresql.conf,the only GUCs I saw where % didn't make sense was the two geco GUCs Heikki mentioned.
 

One thing I don't like is the need to wrap a %-based SET in quotes, but we need to do that for all GUCs that include
units,so presumably there's no good way around it.
 
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



Re: Fractions in GUC variables

From
Michael Paquier
Date:
On Tue, Dec 16, 2014 at 12:19 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 12/15/14 8:56 AM, Heikki Linnakangas wrote:
>> Overall, I feel that this isn't really worth the trouble. We use
>> fractions consistently now, so there isn't much room for confusion over
>> what the current values mean. Using a percentage might be more familiar
>> for some people, but OTOH you'll have to get used to the fractions
>> anyway, unless we change the default output format too, and I'm not in
>> favour of doing that. I suggest that we just drop this, and remove the
>> TODO item.
>
> Agreed.
>
> The patch is sound as far as it goes (I might be inclined to accept
> whitespace between number and % sign), but given the above points and
> the original reason for it having been eliminated, I'm inclined to drop it.
+1.
-- 
Michael