Re: [HACKERS] Fractions in GUC variables

2014-12-21 Thread Michael Paquier
On Tue, Dec 16, 2014 at 12:19 AM, Peter Eisentraut pete...@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


-- 
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] Fractions in GUC variables

2014-12-15 Thread Heikki Linnakangas

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.9020...@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



--
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] Fractions in GUC variables

2014-12-15 Thread Peter Eisentraut
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.


-- 
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] Fractions in GUC variables

2014-12-15 Thread Bruce Momjian
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  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + Everyone has their own god. +


-- 
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] Fractions in GUC variables

2014-12-15 Thread Jim Nasby

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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Fractions in GUC variables

2014-12-07 Thread John Gorman
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.9020...@enterprisedb.com

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.


guc_percent-v1.patch
Description: Binary data

-- 
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] Fractions in GUC variables

2014-12-07 Thread Josh Berkus
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


-- 
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] Fractions in GUC variables

2014-12-07 Thread Michael Paquier
On Mon, Dec 8, 2014 at 4:48 AM, John Gorman johngorm...@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


-- 
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] Fractions in GUC variables

2008-03-11 Thread Bruce Momjian

Added to TODO:

o Consider normalizing fractions in postgresql.conf, perhaps
  using '%'

  http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php


---

Heikki Linnakangas wrote:
 We have these GUC variables that define a fraction of something:
 
 #autovacuum_vacuum_scale_factor = 0.2 # fraction of rel size before
   # vacuum
 #autovacuum_analyze_scale_factor = 0.1# fraction of rel size before
   # analyze
 
 #bgwriter_lru_percent = 1.0   # 0-100% of LRU buffers scanned/round
 #bgwriter_all_percent = 0.333 # 0-100% of all buffers scanned/round
 
 Autovacuum settings use fractions, and bgwriter settings use a 
 percentage. Fortunately these settings are not related so there's not 
 too much potential for confusion, but it seems we should have a common 
 way to define settings like that.
 
 A nice way would be that the base unit would be a fraction, like in the 
 autovacuum settings, but you could add a %-sign to give it as a percent, 
 just like you can use KB/MB etc. I'm not sure if we can do anything for 
 those without breaking backwards-compatibility, though.
 
 Any ideas? The load distributed checkpoints patch adds one more GUC 
 variable like. I'm inclined to follow the example of the bgwriter 
 settings because it's more closely related to them, though I like the 
 autovacuum style more.
 
 -- 
Heikki Linnakangas
EnterpriseDB   http://www.enterprisedb.com
 
 ---(end of broadcast)---
 TIP 4: Have you searched our list archives?
 
http://archives.postgresql.org

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] Fractions in GUC variables

2007-07-16 Thread Bruce Momjian

This has been saved for the 8.4 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---

Heikki Linnakangas wrote:
 We have these GUC variables that define a fraction of something:
 
 #autovacuum_vacuum_scale_factor = 0.2 # fraction of rel size before
   # vacuum
 #autovacuum_analyze_scale_factor = 0.1# fraction of rel size before
   # analyze
 
 #bgwriter_lru_percent = 1.0   # 0-100% of LRU buffers scanned/round
 #bgwriter_all_percent = 0.333 # 0-100% of all buffers scanned/round
 
 Autovacuum settings use fractions, and bgwriter settings use a 
 percentage. Fortunately these settings are not related so there's not 
 too much potential for confusion, but it seems we should have a common 
 way to define settings like that.
 
 A nice way would be that the base unit would be a fraction, like in the 
 autovacuum settings, but you could add a %-sign to give it as a percent, 
 just like you can use KB/MB etc. I'm not sure if we can do anything for 
 those without breaking backwards-compatibility, though.
 
 Any ideas? The load distributed checkpoints patch adds one more GUC 
 variable like. I'm inclined to follow the example of the bgwriter 
 settings because it's more closely related to them, though I like the 
 autovacuum style more.
 
 -- 
Heikki Linnakangas
EnterpriseDB   http://www.enterprisedb.com
 
 ---(end of broadcast)---
 TIP 4: Have you searched our list archives?
 
http://archives.postgresql.org

-- 
  Bruce Momjian  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] Fractions in GUC variables

2007-06-15 Thread Jim Nasby

On Jun 14, 2007, at 7:21 AM, Heikki Linnakangas wrote:

We have these GUC variables that define a fraction of something:

#autovacuum_vacuum_scale_factor = 0.2   # fraction of rel size before
# vacuum
#autovacuum_analyze_scale_factor = 0.1  # fraction of rel size before
# analyze

#bgwriter_lru_percent = 1.0 # 0-100% of LRU buffers scanned/round
#bgwriter_all_percent = 0.333   # 0-100% of all buffers scanned/round

Autovacuum settings use fractions, and bgwriter settings use a  
percentage. Fortunately these settings are not related so there's  
not too much potential for confusion, but it seems we should have a  
common way to define settings like that.


A nice way would be that the base unit would be a fraction, like in  
the autovacuum settings, but you could add a %-sign to give it as a  
percent, just like you can use KB/MB etc. I'm not sure if we can do  
anything for those without breaking backwards-compatibility, though.


Any ideas? The load distributed checkpoints patch adds one more GUC  
variable like. I'm inclined to follow the example of the bgwriter  
settings because it's more closely related to them, though I like  
the autovacuum style more.


We could create bgwrite_*_fraction (portion?) and deprecate  
bgwriter_*_percent...

--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate


[HACKERS] Fractions in GUC variables

2007-06-14 Thread Heikki Linnakangas

We have these GUC variables that define a fraction of something:

#autovacuum_vacuum_scale_factor = 0.2   # fraction of rel size before
# vacuum
#autovacuum_analyze_scale_factor = 0.1  # fraction of rel size before
# analyze

#bgwriter_lru_percent = 1.0 # 0-100% of LRU buffers scanned/round
#bgwriter_all_percent = 0.333   # 0-100% of all buffers scanned/round

Autovacuum settings use fractions, and bgwriter settings use a 
percentage. Fortunately these settings are not related so there's not 
too much potential for confusion, but it seems we should have a common 
way to define settings like that.


A nice way would be that the base unit would be a fraction, like in the 
autovacuum settings, but you could add a %-sign to give it as a percent, 
just like you can use KB/MB etc. I'm not sure if we can do anything for 
those without breaking backwards-compatibility, though.


Any ideas? The load distributed checkpoints patch adds one more GUC 
variable like. I'm inclined to follow the example of the bgwriter 
settings because it's more closely related to them, though I like the 
autovacuum style more.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org