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 1sdxKU-002b8G-GD for pgsql-in-general@arkaria.postgresql.org; Tue, 13 Aug 2024 19:37:14 +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 1sdxKS-0064wb-JL for pgsql-in-general@arkaria.postgresql.org; Tue, 13 Aug 2024 19:37:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sdxKS-0064vv-95 for pgsql-in-general@lists.postgresql.org; Tue, 13 Aug 2024 19:37:12 +0000 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sdxKQ-004hWE-5F for pgsql-in-general@postgresql.org; Tue, 13 Aug 2024 19:37:11 +0000 Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5bd13ea7604so4428557a12.1 for ; Tue, 13 Aug 2024 12:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723577828; x=1724182628; 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=4VzjO7Q1ufK58zl5sIVTHksiZoW8N9Ar6XvsrOFWQo8=; b=L7EKiQTqMlTME4hp9dvzjjrspqqCWK4aXCvHK7HII/9h5Bl49cMY9MJRTODTT6jLf3 7/3V8J4Fjarcc6xm3XtjlSc/gc50xIwiEG8YeQ6QeeHtDJUX1rN+YUkIONFBCjK59RED lr6oUFwWy49DwYQTK/HlPtyxhxjLb1ZJmXi6rAoXEqX93eDiKY0od6uZIvR9XpZGXkjP Un9vsi9HF7ZqNXHSXQ4UGrdJAzfPFrhSW0Oe7n9lTy471mJz6AjKAqXNggVBnglw7SlY TIxJpYgjXkViwgIKh1DkHCAOuKefLtbdZvWMEenO+y8m6BmrperI+4/sMf0aNy4JTPQC bE3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723577828; x=1724182628; 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=4VzjO7Q1ufK58zl5sIVTHksiZoW8N9Ar6XvsrOFWQo8=; b=ArkPcr3GzlUO1f8Zxor+AV8H0GoTQ4HKp5mVYzIS6rdfQgr0McFSaIkgmmtNkkEM3T +3CSTIYI8eQMg6dk7eDR7ud6X3tO7rlbqt1AG2vbDzT6y2iRniuHsQ7wcACqnblmFnRA AL5eN12j8iuS2FMbpFcV7u6UVm2OXT0BLPk7X20Lp8vkn6GM7Chj9CFHLuhZvUCp3N3m +jYGkK3kc9GXAMOTg1iEoBYKRo10avPvRAyo7ypoBWEJJpbujcpyAZ+pKTbibi0JVEAv RlwF9EOIgzU+ZbhOF7boD2wLuj66uTfeBmGrCLrEB7HfvIEKxua58mHWylUfv5tuND5R tE1w== X-Forwarded-Encrypted: i=1; AJvYcCWf+fovk6lHBKb8Vptpdt2fVjaHJVt2UgB9kJmqRBA02WXLaBxMDDRZMg95BBGH1hl9t3AIRMOcUTl/BQuEnUApEi4hE8nefh2Y5FGeMp4s X-Gm-Message-State: AOJu0Yw6+oA6WHWcnizSobXdPnxCcxmvMlR/Q5oXAUtVmR01bKKBkjRy gnlZSBpMqZbV668TBihS0hAtl6lfxWRBMnHmnDSmJV1RClp1z3O69dDfbJ2wzlbOnhhC/GOgxTQ HYAQp5TJosjJtnIwIbIkCIMK9NsA= X-Google-Smtp-Source: AGHT+IFnKk2av2KSW5A5+vhQQ/JUtn8UhUOLAWuTgZhmOJ9HbVKYq1K7iC9MP7j6ckzAsCySChdeSGQvW14gx2eJM/Y= X-Received: by 2002:a17:907:84c:b0:a7a:bc34:a4c9 with SMTP id a640c23a62f3a-a83670bf16cmr21148466b.69.1723577828051; Tue, 13 Aug 2024 12:37:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Durgamahesh Manne Date: Wed, 14 Aug 2024 01:08:53 +0530 Message-ID: Subject: Re: autovacuum freeze recommendations at table level To: semab tariq , laurenz.albe@cybertec.at Cc: pgsql-general@lists.postgresql.org, pgsql-in-general@postgresql.org, Christoph Berg Content-Type: multipart/alternative; boundary="0000000000002f12e4061f95bc22" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002f12e4061f95bc22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Semab ALTER TABLE table SET ( autovacuum_freeze_max_age =3D 60000000,(6 crores) autovacuum_multixact_freeze_max_age =3D 60000000,(6 crores) autovacuum_freeze_min_age =3D 0 ); I set this but autovacuum to prevent wraparound runs for every 10 minutes on the table being modified in this case How to minimize the impact of this ? There is no option to set naptime at table level I could see total records around 40 lakhs that are being modified Toast considers large objects but I use parameters without toast. Regards, Durga Mahesh Manne On Mon, Aug 12, 2024 at 10:07=E2=80=AFPM semab tariq wrote: > Hi Durga > > *autovacuum_freeze_max_age* specifies the maximum age (in transactions) > that a table's tuples can reach before a vacuum is forced to prevent > transaction ID wraparound. when the age of the oldest tuple in the table > exceeds this value, an autovacuum is triggered to freeze the tuples. > *Recommendation =3D 20000000 -> 150000000 * > > *autovacuum_multixact_freeze_max_age *It is similar to above, but applies > to multi-transaction IDs (used for shared row locks). when the age of the > oldest multi-transaction ID exceeds this value, an autovacuum is triggere= d > to freeze the multi-transaction IDs. > *Recommendation =3D 20000000 -> 150000000* > > *autovacuum_freeze_min_age* specifies the minimum age (in transactions) > that a tuple must reach before it is considered for freezing. Lowering th= is > value can cause more frequent freezing, which can increase the overhead o= f > autovacuum. > *Recommendation =3D 0 -> 50000000* > > Thanks, Semab > > On Sun, Aug 11, 2024 at 11:12=E2=80=AFAM Durgamahesh Manne < > maheshpostgres9@gmail.com> wrote: > >> Hi Respected Team, >> >> Could you please let me know that how this freeze parameters work >> Update query runs on table through which data being modified daily in >> this case >> Total records in table is about 20lakhs >> current setting for this table is >> Access method: heap >> if it reaches > 0.1*2000000+1000 =3D 2,10,000 as per the formula autovac= uum >> triggers >> Options: fillfactor=3D85, autovacuum_vacuum_cost_delay=3D0, >> autovacuum_vacuum_cost_limit=3D3000, parallel_workers=3D6, >> autovacuum_vacuum_scale_factor=3D0.1, autovacuum_vacuum_threshold=3D1000= , >> autovacuum_freeze_max_age=3D20000000, >> autovacuum_multixact_freeze_max_age=3D20000000, autovacuum_freeze_min_ag= e=3D0 >> >> How autovacuum freeze parameters work.Give me some recommendations to >> improve the performance better than now >> Ex :ALTER TABLE table SET ( >> autovacuum_freeze_max_age =3D 20000000,(2 crores) >> autovacuum_multixact_freeze_max_age =3D 20000000,(2 crores) >> autovacuum_freeze_min_age =3D 0 >> ); >> Regards, >> Durga Mahesh >> > --0000000000002f12e4061f95bc22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Semab

ALTER TABLE ta= ble SET (
=C2=A0 =C2=A0autovacuum_freeze_max_age =3D 60000000,(6 crores)=
=C2=A0 =C2=A0autovacuum_multixact_freeze_max_age =3D 60000000,(6 crores= )
=C2=A0 =C2=A0autovacuum_freeze_min_age =3D 0
);
I set= this but autovacuum to prevent wraparound runs for every 10 minutes on the= table being modified in this case=C2=A0
How to minimize the impa= ct of this ?
There is no option to set naptime at table level
I could see total records around 40 lakhs that are being modified=C2= =A0
Toast considers large objects but I use parameters without to= ast.

Regards,
Durga Mahesh Manne


On Mon, Aug 12, 2024 at 10:07=E2=80=AFPM semab tariq <semabtariq1@gmail.com> wrote:
Hi Durg= a

autovacuum_freeze_max_age=C2=A0specifies the maximum = age (in transactions) that a table's tuples can reach before a vacuum i= s forced to prevent transaction ID wraparound. when the age of the oldest t= uple in the table exceeds this value, an autovacuum is triggered to freeze = the tuples.
Recommendation =3D=C2=A020000000 ->=C2=A0150000= 000=C2=A0

autovacuum_multixact_freeze_max_age It i= s=C2=A0similar to above, but applies to multi-transaction IDs (used = for shared row locks). when the age of the oldest multi-transaction ID exce= eds this value, an autovacuum is triggered to freeze the multi-transaction = IDs.
Recommendation =3D=C2=A020000000 ->=C2=A0150000000
<= div>
autovacuum_freeze_min_age
specifies the minimum age (in tran= sactions) that a tuple must reach before it is considered for freezing. Low= ering this value can cause more frequent freezing, which can increase the o= verhead of autovacuum.
Recommendation =3D 0 ->=C2=A050000000

Thanks, Semab

On Sun, Aug 11, 2024 at= 11:12=E2=80=AFAM Durgamahesh Manne <maheshpostgres9@gmail.com> wrote:
Hi=C2= =A0 Respected Team,

Could you please=C2=A0let me know th= at how this freeze parameters work
Update query runs on table=C2= =A0 through which data being modified daily in this case
Total re= cords in table is about 20lakhs
current setting for this=C2=A0tab= le is=C2=A0
Access method: heap
if it reaches > 0.1*= 2000000+1000 =3D 2,10,000 as per the formula autovacuum triggers
Options= : fillfactor=3D85, autovacuum_vacuum_cost_delay=3D0, autovacuum_vacuum_cost= _limit=3D3000, parallel_workers=3D6, autovacuum_vacuum_scale_factor=3D0.1, = autovacuum_vacuum_threshold=3D1000, autovacuum_freeze_max_age=3D20000000, a= utovacuum_multixact_freeze_max_age=3D20000000, autovacuum_freeze_min_age=3D= 0

How autovacuum freeze parameters work.Give m= e some recommendations to improve the performance better than now=C2=A0
Ex :ALTER TABLE table SET (
=C2=A0 =C2=A0autovacuum_freeze_max_ag= e =3D 20000000,(2 crores)
=C2=A0 =C2=A0autovacuum_multixact_freeze_max_a= ge =3D 20000000,(2 crores)
=C2=A0 =C2=A0autovacuum_freeze_min_age =3D 0<= br>);
Regards,
Durga Mahesh=C2=A0
--0000000000002f12e4061f95bc22--