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 1kxnhA-00074O-22 for pgsql-admin@arkaria.postgresql.org; Fri, 08 Jan 2021 09:04:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kxnh8-0008SX-Bi for pgsql-admin@arkaria.postgresql.org; Fri, 08 Jan 2021 09:04:30 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kxnh8-0008SQ-4e for pgsql-admin@lists.postgresql.org; Fri, 08 Jan 2021 09:04:30 +0000 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kxnh4-000333-Kr for pgsql-admin@postgresql.org; Fri, 08 Jan 2021 09:04:28 +0000 Received: by mail-ej1-x62d.google.com with SMTP id w1so13458880ejf.11 for ; Fri, 08 Jan 2021 01:04:26 -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:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=i0cccnPMvWKif0w6BaqKDDwXspMp7coYMhPt5v8lM0Y=; b=rigbJPQ9NnBrPnkis7c3LUhX+Y2QL+q7mXiG2rh5ZZSKL/g+wvNgv7WsBQShO079c7 CF+nSVUV8BBiUTPawcAJjmnPKmX2spjVhQCDxojy51chOKsCilmvFzFpmUTjL1FocM5p InnNskQ2zRXS1Y3uTkCIT2RYaFFVkqzj5YCEsGKf3OtaaKNZ8ZPU8tmmudAql2gQZJLB +GaRs/7AF+ilTi9azjCuQ55dmqCYwHC+9K665YfjMtwYkGPsyTh5hd5v9P9zmvuFTgXY dOQ3XilLP4Lwy1bxVusYhap0NqDkxdayK6rziO+vcszMjlyzeOGIuyO9na27JD+hhw9P SW0Q== 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:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=i0cccnPMvWKif0w6BaqKDDwXspMp7coYMhPt5v8lM0Y=; b=hWlJyh97dYjszGvsvzCywqETwBGcvp5c9JeCBgaGBcQgn1yfxc3nO9ZmUr9auxgA8T KwIDvzy/TcfMW51IgtcSuX3cNMjpPyzWj0M23G2LiqRHLISzlPPNzE8Gf9prFFv390ba tzP/5qszd6owYnMd4Vo0aGSCNLyzZHhCzqXeGxuyAh1mvmfIeOwv+KTHI97+1S018nEy 6wQc7stm32rvmUn0xm4m2AONey5OWz/3hCYXcFm+iuftM2Hieq+jjONJOKiL7lAV1gcK Nqg/mXFUv4LZkYinN1+eJk3wkvZAxx7v+LwzeFMxJD7NFBx2oIpByyeHx4CE+GdxCRXQ bAzA== X-Gm-Message-State: AOAM531l9J2NRJcPZTxUKj9RIEG8CX05mZHewzlBXs4bnG33hKmR0khu u1aGI61Hkrq10zCsHY9MSFvczw== X-Google-Smtp-Source: ABdhPJyZFXz3lNLGm/pEranmvAdMqKdJcIYtBaBW+9hmgiOUxEV3xPxAt0SodmE7k991PIqkeha8Hg== X-Received: by 2002:a17:907:447d:: with SMTP id oo21mr2013998ejb.367.1610096665116; Fri, 08 Jan 2021 01:04:25 -0800 (PST) Received: from localhost.localdomain (217-149-174-246.nat.highway.telekom.at. [217.149.174.246]) by smtp.gmail.com with ESMTPSA id f18sm3482425edt.60.2021.01.08.01.04.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Jan 2021 01:04:24 -0800 (PST) Message-ID: <277279e0a7b59a5ac942976aaaf85e1d74d7034e.camel@cybertec.at> Subject: Re: autovacuum_analyze_scale_factor and autovacuum_analyze_scale_factor From: Laurenz Albe To: Henry Francisco Garcia Cortez Cc: pgsql-admin@postgresql.org Date: Fri, 08 Jan 2021 10:04:23 +0100 In-Reply-To: References: <38c4371df337331ce4c8d97c3ea1ecce30fc4988.camel@cybertec.at> 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: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, 2021-01-07 at 10:56 -0600, Henry Francisco Garcia Cortez wrote: > El mié, 6 ene 2021 a las 19:53, Laurenz Albe () escribió: > > > 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. > > Thanks for the information Laurenz Albe I have another question what will be effect > if there are autovacuums running all the time, what will be settings you could suggest me for > autovacuum_vacuum_scale_factor and autovacuum_analyze_scale_factor Unless there are indications to choose different values, stick with the default values of 0.1 and 0.2. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com