Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIlIE-00060e-0t for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Nov 2017 00:59:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIlID-0006MG-Bx for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Nov 2017 00:59:33 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eIlID-0006Lo-5M for pgsql-hackers@lists.postgresql.org; Sun, 26 Nov 2017 00:59:33 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eIlI5-0004Nd-25 for pgsql-hackers@postgresql.org; Sun, 26 Nov 2017 00:59:32 +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 vAQ0xJb6008328; Sat, 25 Nov 2017 19:59:19 -0500 From: Tom Lane To: Michael Paquier cc: Kyotaro HORIGUCHI , Sawada Masahiko , "pgsql-hackers@postgresql.org" , Robert Haas Subject: Re: [HACKERS] More stats about skipped vacuums In-reply-to: References: <20171116.193402.26276109.horiguchi.kyotaro@lab.ntt.co.jp> <20171121.160957.124460918.horiguchi.kyotaro@lab.ntt.co.jp> <1323.1511624064@sss.pgh.pa.us> Comments: In-reply-to Michael Paquier message dated "Sun, 26 Nov 2017 08:51:53 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8326.1511657959.1@sss.pgh.pa.us> Date: Sat, 25 Nov 2017 19:59:19 -0500 Message-ID: <8327.1511657959@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Michael Paquier writes: > I am not arguing about skipped vacuuum data here (don't think much of > it by the way), but of the number of index scans done by the last > vacuum or autovacuum. This helps in tunning autovacuum_work_mem and > maintenance_work_mem. The bar is still too high for that? I'd say so ... that's something the average user will never bother with, and even if they knew to bother, it's far from obvious what to do with the information. Besides, I don't think you could just save the number of scans and nothing else. For it to be meaningful, you'd at least have to know the prevailing work_mem setting and the number of dead tuples removed ... and then you'd need some info about your historical average and maximum number of dead tuples removed, so that you knew whether the last vacuum operation was at all representative. So this is sounding like quite a lot of new counters, in support of perhaps 0.1% of the user population. Most people are just going to set maintenance_work_mem as high as they can tolerate and call it good. regards, tom lane