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 1h2jB7-0004FN-Oe for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Mar 2019 21:06:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h2jB6-0001db-6u for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Mar 2019 21:06:44 +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 1h2jB5-0001Yb-S4 for pgsql-hackers@lists.postgresql.org; Sat, 09 Mar 2019 21:06:44 +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 1h2jB3-000586-EG for pgsql-hackers@lists.postgresql.org; Sat, 09 Mar 2019 21:06:42 +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 x29L6XOp001864; Sat, 9 Mar 2019 16:06:33 -0500 From: Tom Lane To: Gavin Flower 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: 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> Comments: In-reply-to Gavin Flower message dated "Sun, 10 Mar 2019 09:36:59 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1862.1552165593.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Sat, 09 Mar 2019 16:06:33 -0500 Message-ID: <1863.1552165593@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Gavin Flower writes: > Hope about  keeping the default unit of ms, but converting it to a > 'double' for input, but storing it as int (or long?) number of > nanoseconds.  Gives finer grain of control withouthaving to specify a > unit, while still allowing calculations to be fast? Don't really see the point. The only places where we do any calculations with the value are where we're about to sleep, so shaving a few nanosec doesn't seem very interesting. regards, tom lane