Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h2kEq-0006pT-Qw for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Mar 2019 22:14:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h2kEo-0002rf-Lo for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Mar 2019 22:14:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h2kEo-0002rY-BE for pgsql-hackers@lists.postgresql.org; Sat, 09 Mar 2019 22:14:38 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h2kEh-0006WT-JO for pgsql-hackers@lists.postgresql.org; Sat, 09 Mar 2019 22:14:37 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x29MEPUp003812; Sat, 9 Mar 2019 17:14:25 -0500 From: Tom Lane To: Julien Rouhaud cc: Andrew Dunstan , David Rowley , Jeff Janes , Jeremy Schneider , Joe Conway , Peter Geoghegan , PostgreSQL Hackers Subject: Re: Should we increase the default vacuum_cost_limit? In-reply-to: <1798.1552165479@sss.pgh.pa.us> References: <241b80ab-7af0-c606-7b2c-b0a5d6be696a@joeconway.com> <4a068b09-5a6f-e975-07c9-2333fcef0a8a@amazon.com> <30411a5b-ef11-71ef-e9ee-4d26ef3fd0c0@2ndQuadrant.com> <21034.1552068630@sss.pgh.pa.us> <13d143dd-0a44-0c16-218c-bc924b5922f0@2ndQuadrant.com> <26656.1552096451@sss.pgh.pa.us> <28720.1552101086@sss.pgh.pa.us> <203719fc-1970-4a49-8013-eba3fd109b19@2ndQuadrant.com> <24300.1552154154@sss.pgh.pa.us> <1798.1552165479@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Sat, 09 Mar 2019 16:04:39 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3810.1552169665.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 09 Mar 2019 17:14:25 -0500 Message-ID: <3811.1552169665@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk BTW ... I noticed while fooling with this that GUC's out-of-range messages can be confusing: regression=3D# set vacuum_cost_delay =3D '1s'; ERROR: 1000 is outside the valid range for parameter "vacuum_cost_delay" = (0 .. 100) One's immediate reaction to that is "I put in 1, not 1000". I think it'd be much clearer if we included the unit we'd converted to, thus: ERROR: 1000 ms is outside the valid range for parameter "vacuum_cost_dela= y" (0 .. 100) (Notice that this also implicitly tells what units the range limits are being quoted in. We could repeat the unit name in that part, viz "(0 .. 100 ms)", but it seems unnecessary.) A small problem with this idea is that GUC_UNIT_[X]BLOCK variables don't really have a natural unit name. If we follow the lead of pg_settings, such errors would look something like ERROR: 1000 8kB is outside the valid range for ... I can't think of a better idea, though, and it'd still be clearer than what happens now. Barring objections I'll go make this happen. regards, tom lane