Re: [Suspect SPAM] Re: Should we increase the default vacuum_cost_limit?
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: rjuju123@gmail.com
Cc: david.rowley@2ndquadrant.com, tgl@sss.pgh.pa.us,
andrew.dunstan@2ndquadrant.com, jeff.janes@gmail.com,
schnjere@amazon.com, mail@joeconway.com, pg@bowt.ie,
pgsql-hackers@lists.postgresql.org
Date: 2019-03-12T03:31:28Z
Lists: pgsql-hackers
Attachments
- PoC_int_guc_representation.patch (text/x-patch) patch
At Mon, 11 Mar 2019 13:57:21 +0100, Julien Rouhaud <rjuju123@gmail.com> wrote in <CAOBaU_a2tLyonOMJ62=SiDmo84Xo1fy81YA8K=B+=OtTc3sYSQ@mail.gmail.com> > On Mon, Mar 11, 2019 at 10:03 AM David Rowley > <david.rowley@2ndquadrant.com> wrote: > > > > On Mon, 11 Mar 2019 at 09:58, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > The second patch is a delta that rounds off to the next smaller unit > > > if there is one, producing a less noisy result: > > > > > > regression=# set work_mem = '30.1GB'; > > > SET > > > regression=# show work_mem; > > > work_mem > > > ---------- > > > 30822MB > > > (1 row) > > > > > > I'm not sure if that's a good idea or just overthinking the problem. > > > Thoughts? > > > > I don't think you're over thinking it. I often have to look at such > > settings and I'm probably not unique in when I glance at 30822MB I can > > see that's roughly 30GB, whereas when I look at 31562138kB, I'm either > > counting digits or reaching for a calculator. This is going to reduce > > the time it takes for a human to process the pg_settings output, so I > > think it's a good idea. > > Definitely, rounding up will spare people from wasting time to check > what's the actual value. +1. I don't think it overthinking, too. Anyone who specifies memory size in GB won't care under-MB fraction. I don't think '0.01GB' is a sane setting but it being 10MB doesn't matter. However, I don't think that '0.1d' becoming '2h' is reasonable. "10 times per day" is "rounded" to "12 times per day" by that. Is it worth showing values with at most two or three fraction digits instead of rounding the value on setting? In the attached PoC patch - instead of the 'roundoff-fractions-harder' patch - shows values in the shortest exact representation. work_mem: 31562138 => '30.1 GB' 31562137 => '31562137 kB' '0.1GB' => '0.1 GB' '0.01GB' => '0.01 GB' '0.001GB' => '1049 kB' lock_timeout: '0.1h' => '6 min' '90 min' => '90 min' '120 min' => '2 h' '0.1 d' => '0.1 d' regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Allow fractional input values for integer GUCs, and improve rounding logic.
- 1a83a80a2fe5 12.0 landed
-
Reduce the default value of autovacuum_vacuum_cost_delay to 2ms.
- cbccac371c79 12.0 landed
-
Revert "Increase the default vacuum_cost_limit from 200 to 2000"
- 52985e4fea75 12.0 landed
-
Convert [autovacuum_]vacuum_cost_delay into floating-point GUCs.
- caf626b2cd47 12.0 landed
-
Include GUC's unit, if it has one, in out-of-range error messages.
- 28a65fc3607a 12.0 landed
-
Disallow NaN as a value for floating-point GUCs.
- ac75959cdc07 12.0 landed
- f9ec64df8f25 10.8 landed
- e04bb261633d 9.4.22 landed
- d8f8183c0467 9.5.17 landed
- bc2232f2f544 11.3 landed
- 5aafedc2fdbd 9.6.13 landed
-
Increase the default vacuum_cost_limit from 200 to 2000
- bd09503e633b 12.0 landed