Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kxKUc-0007sG-9O for pgsql-admin@arkaria.postgresql.org; Thu, 07 Jan 2021 01:53:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kxKUb-0003DG-7w for pgsql-admin@arkaria.postgresql.org; Thu, 07 Jan 2021 01:53:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kxKUa-0003Cz-SB for pgsql-admin@lists.postgresql.org; Thu, 07 Jan 2021 01:53:37 +0000 Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kxKUY-0001Rk-ET for pgsql-admin@postgresql.org; Thu, 07 Jan 2021 01:53:36 +0000 Received: by mail-wm1-x332.google.com with SMTP id n16so4090832wmc.0 for ; Wed, 06 Jan 2021 17:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=6QkHdzfTXDxhCHYURj/Q6CAXSPoG6u6mxP4Mh4z1S0g=; b=p/6A1pR9W0WljBVR/OhtfLYFToRyuaWkswx3qZbPFayZOUtyUmcuqSWs96JEVPiz9V 0EcZrP84+o84zIwf3G5aMyT2k4ylkiYhMLAA+x75LJb6jNUxkh0AVVIH796lb3TX/Xjw K66Zhodhbe8fTnQ4l8i8i8wqjdlID1T2NP5K1T5PWH2QHnaPTzA4MSDPd1MOU8sG0Uqe 57xuG9v2vZJzbQgryA1f3LWfmUBiMlMuSa6yE54NlGDvVFSvN5JkvHwE3/Zp7RzjnbU0 8IzKM9ju3zFO6i8Fo+X79QIdot+FFSrfrmz2EiaKz0MMv8MjbLjCrowq0nLy5HnYMBe5 nzLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=6QkHdzfTXDxhCHYURj/Q6CAXSPoG6u6mxP4Mh4z1S0g=; b=uHKp2w4GKijY10SHz/tkyGYlB0g4Snk7X9Usgvm0oTg2Wxl/r4oOgYRRYZ4t2iqJqv JAGy9ogz3M8jOR3041uscufgBsr+izkvwHZz3Gigsx+e1HEPZm4EPx5af7lsvwF7wU+p 0hrMaFW1mXU0+j68b80KYimBVo+TTusVON8FMfsna11MuBeNXi5YTqK5qT0qi3CEO8Nz oChhB/crg7C3PQ6HKgA+OyuckoNWsCiAE1dZO+Po4HqkLWpcNDMBi6o79Z+XZ2oClHfR 6Zqkv6pgV7cwFtes36Ov+uST6HnBrnsShCIzNUKM4ycKq1hs1E0eBIWq8OfDSyzv64jt UtfA== X-Gm-Message-State: AOAM531wAP9LARw2gl0xHQTYsJ77KD1tloAFqjGX4I/FltK35eOlwvu5 FxXMnq6NUKuMihXGnnJWj0LO7Q== X-Google-Smtp-Source: ABdhPJx5ov7rq59KqqS8ko37vuXNXrprwhPaMKTrChiieDlf1bA7Gd188J4Luf07URRLZM+L/YzLpA== X-Received: by 2002:a1c:9a4d:: with SMTP id c74mr6131424wme.5.1609984412864; Wed, 06 Jan 2021 17:53:32 -0800 (PST) Received: from localhost.localdomain (178-190-179-204.adsl.highway.telekom.at. [178.190.179.204]) by smtp.gmail.com with ESMTPSA id n16sm5410435wrj.26.2021.01.06.17.53.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jan 2021 17:53:32 -0800 (PST) Message-ID: <38c4371df337331ce4c8d97c3ea1ecce30fc4988.camel@cybertec.at> Subject: Re: autovacuum_analyze_scale_factor and autovacuum_analyze_scale_factor From: Laurenz Albe To: Henry Francisco Garcia Cortez , pgsql-admin@postgresql.org Date: Thu, 07 Jan 2021 02:53:31 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, 2021-01-06 at 11:05 -0600, Henry Francisco Garcia Cortez wrote: > I have a question why settings default postgresql has autovacuum_vacuum_scale_factor in 0.2 > is higher than autovacuum_analyze_scale_factor 0.1, so If want to tune these parameters, > I always must leave autovacuum_vacuum_scale_factor higher than autovacuum_analyze_scale_factor, > for instance I wanted to leave autovacuum_vacuum_scale_factor in 0.002 and > autovacuum_analyze_scale_factor in 0.001 The autovacuum scale factor has been twice the autoanalyze scale factor since the beginning. You could search the archives from around 2004 for a reason, but I'd say it might have to do with the fact that ANALYZE is much cheaper than VACUUM, and that the impact of bad statistics is usually more severe than the impact of some dead tuples. But there is no need for you to keep it that way when you change the parameters. For example, if you want to speed up index only scans, you may want to set "autovacuum_vacuum_scale_factor" to something like 0.01, but leave "autovacuum_analyze_scale_factor" at the default value. The values that you suggest seem much too low - that will result in autovacuum running all the time. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com