Re: [Suspect SPAM] Re: Should we increase the default vacuum_cost_limit?

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: rjuju123(at)gmail(dot)com
Cc: david(dot)rowley(at)2ndquadrant(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, andrew(dot)dunstan(at)2ndquadrant(dot)com, jeff(dot)janes(at)gmail(dot)com, schnjere(at)amazon(dot)com, mail(at)joeconway(dot)com, pg(at)bowt(dot)ie, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [Suspect SPAM] Re: Should we increase the default vacuum_cost_limit?
Date: 2019-03-12 03:45:59
Message-ID: 20190312.124559.221664593.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sorry, I sent a wrong patch. The attached is the right one.

At Mon, 11 Mar 2019 13:57:21 +0100, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote in <CAOBaU_a2tLyonOMJ62=SiDmo84Xo1fy81YA8K=B+=OtTc3sYSQ(at)mail(dot)gmail(dot)com>
> On Mon, Mar 11, 2019 at 10:03 AM David Rowley
> <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> >
> > On Mon, 11 Mar 2019 at 09:58, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

Attachment Content-Type Size
PoC_int_guc_representation.patch text/x-patch 3.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-03-12 04:56:18 Re: Why don't we have a small reserved OID range for patch revisions?
Previous Message Kyotaro HORIGUCHI 2019-03-12 03:31:28 Re: [Suspect SPAM] Re: Should we increase the default vacuum_cost_limit?