Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sRB7A-00DiPC-4J for pgsql-general@arkaria.postgresql.org; Tue, 09 Jul 2024 13:42:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sRB78-00FZMd-94 for pgsql-general@arkaria.postgresql.org; Tue, 09 Jul 2024 13:42:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sRB77-00FZMV-UP for pgsql-general@lists.postgresql.org; Tue, 09 Jul 2024 13:42:37 +0000 Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sRB71-001CvQ-11 for pgsql-general@postgresql.org; Tue, 09 Jul 2024 13:42:36 +0000 Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-52ea2ce7abaso6941956e87.0 for ; Tue, 09 Jul 2024 06:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720532548; x=1721137348; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x58zQESdCQ/IJ61APgQbV8ygjbq9wLN1gmnMkGw8avI=; b=Ol0QJUPz1EoaGdI6bfwiMCSFxYB+8afMWs5qFujatiP8maMIDFyfRHLK13YtD0RH1j BHkweyJoaXVMQMNRBGC50Ht+4LGkHmMvTK8yG6onKdOUBFgm1QNVOscMsQ7Tnl1mwLDg gqS7WML9s63XWJ8k4tSfAsXypyLq+39347Hzk75epIvo2PUGbk3Ok5F4xErQubUPWa0D o1AJjYeNXPNxJQKXuAjxi5dzQdnRxa6IQ3xC9p5UTmNXeRHfaMgUjGnYJndF77kQIFYb 8RIWo3GYYtmo68XmykMjl7XgUNCa8aWFljb+I72pH/sdWS8n9YiSw/CJrQRcdGVQ8vIC ZzjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720532548; x=1721137348; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x58zQESdCQ/IJ61APgQbV8ygjbq9wLN1gmnMkGw8avI=; b=M7JnLgljqaj59oftpcRg9cNPDv9Jx66V1wAA2ir2QsNBdoXPd1kQLNIhVbIJ+BCrUO U4hd2Bk96FDR7LCNgoXe5bMxOddF+e/AdO6ZiXVTCpjE68DdP507+Cxe3uRoYJDM/suR Jud3KQ/u4hO/e0miW0rGJCAUDIeWbRF8WaN8+wOAxoh+2p2O+WY9xhTXWturj2A7Mrw9 NdhSv7C8YKPGz0LWf/yXsabm8T4eJgqT/uk/AI+sLld2fnTcdl00qgl9B6rfWFWSEgT+ Ezaw6mjP3ZQHbrt7NXv8yQMEhC4AqqMjQJ1axUu47TdUZ8tduLTwQ4nVd7poD30VmC/O xAAg== X-Gm-Message-State: AOJu0YwbEAEujFdK+/dadWAphfUhfQjJHGiD7mPUoRWuzlM+c3qtzBuW MwhET/FxzODBd6Qv4qqNTURy+DBCcV2D7rr0gYuwjJupSL70Z8TuvQM8+CgYFz+nLm6mydX6OqP Gi5mKaC/c9b41WvLd20moyyVkR7E= X-Google-Smtp-Source: AGHT+IFqCebDXrL1DFDxEcpELO3o8Qwv9HnGeL+R0fAZZugm/9NvL2WKYsloiBBJmQypEIs6iaSsUUKHsC3EeWFpIys= X-Received: by 2002:a05:6512:33cd:b0:52c:d9b3:2b06 with SMTP id 2adb3069b0e04-52eb99d59d7mr2064143e87.58.1720532548162; Tue, 09 Jul 2024 06:42:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Muhammad Ikram Date: Tue, 9 Jul 2024 18:42:11 +0500 Message-ID: Subject: Re: autovacuum_vacuum_cost_delay To: "Shenavai, Manuel" Cc: pgsql-general Content-Type: multipart/alternative; boundary="0000000000005b9d45061cd0b314" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005b9d45061cd0b314 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Shenvail, Based on what I could understand, Lower value will cause more frequent run of Autovacuum. Will have less delay between processing data chunks but will put more load on the I/O system. Autovacuum tasks will complete faster. Cleanup of dead tuples and blots will be quicker thus increasing performance in the cases where tables are heavily updated/deleted. Higher values will result in longer delays between processing data chunks thus slowing down the completion of autovacuum tasks. Autovacuum will have less I/O load for its tasks. Database performance will be degraded if operations are more update/delete intensive. Dead tuples and bloat will take longer to be cleaned up. It can be beneficial for performance of other database operations, especially if your system is I/O-bound. Can also be helpful when system resources are less Regards, Muhammad Ikram Bitnine Global. On Tue, Jul 9, 2024 at 4:38=E2=80=AFPM Shenavai, Manuel wrote: > Hi everyone, > > > > We are doing some tests with different autovacuum settings. > > > > Looking at autovacuum_vacuum_cost_delay: > > > https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GU= C-AUTOVACUUM-VACUUM-COST-DELAY > > > > Can someone help to understand what a high or low value of this setting > really means? Would it be OK to set this to 0? If not, why not? > > > > Thanks in advance & > Best regards, > > Manuel > --=20 Muhammad Ikram --0000000000005b9d45061cd0b314 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Shenvail,

Based on what I could unde= rstand,

Lower value will cause more frequent run o= f Autovacuum. Will have less=C2=A0delay=C2=A0between processing data chunks= but will put more load on the I/O system. Autovacuum tasks will complete f= aster. Cleanup of dead tuples and blots will be quicker thus increasing per= formance in the cases where tables are heavily updated/deleted.
<= br>
Higher values will result in longer delays between processing= data chunks thus slowing down the completion of autovacuum tasks. Autovacu= um will have less I/O load for its tasks. Database performance will be degr= aded if operations are more update/delete intensive. Dead tuples and bloat = will take longer to be cleaned up.=C2=A0
It can be beneficial=C2= =A0 for performance of other database operations, especially if your system= is I/O-bound. Can also be helpful when system resources are less

Regards,
Muhammad Ikram
Bitnine Global.=


On Tue, Jul 9, 2024 at 4:38=E2=80=AFPM Shenavai, Manue= l <manuel.shenavai@sap.com> wrote:

Hi everyone,

=C2=A0

We are doing some tests with di= fferent autovacuum settings.

=C2=A0

Looking at autovacuum_vacuum_co= st_delay:

https://www.postgresql.org/docs/current/runtime= -config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY<= /span>

=C2=A0

Can someone help to understand = what a high or low value of this setting really means? Would it be OK to se= t this to 0? If not, why not?

=C2=A0

Thanks in advance &
Best regards,

Manuel



--
Muhammad Ikram

--0000000000005b9d45061cd0b314--