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 1sdY35-00Ga33-I7 for pgsql-general@arkaria.postgresql.org; Mon, 12 Aug 2024 16:37:35 +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 1sdY33-00Gnbr-4g for pgsql-general@arkaria.postgresql.org; Mon, 12 Aug 2024 16:37:33 +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 1sdY32-00Gnbe-LJ for pgsql-general@lists.postgresql.org; Mon, 12 Aug 2024 16:37:32 +0000 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sdY2z-004Npj-V1 for pgsql-general@lists.postgresql.org; Mon, 12 Aug 2024 16:37:31 +0000 Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-710d1de6e79so3034913b3a.0 for ; Mon, 12 Aug 2024 09:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723480649; x=1724085449; darn=lists.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=SUsnCibnMH7ivE2QYlQBgp1mKBBeANli3TzS8KQmWFE=; b=XLsyyPZDGCK7NF3Rwiq0gcwP4urxP/vycDXJFnO+9MNeFoRrYfjVH74AOm+SWKHjVw TfrQHFx8Ledk79d9vuNaQHz8kIYgFgXFMjZUJVv1vHrpsDg7XmsGmefYqwcedbnz7O9y eZ0dYpux4OKiSiGKhdnT5xP2qGpIyDJla/vIO2bx1IW8BuxQipq9XLJg5E5ecvyNaOG1 V3cwIz/LE3JHwi3GG53n7e9CV+ejUGsJ70Vla8/xSn+/FHmDjWeEI7W26PgHuLz+gzW5 k7+0vLewNENkQj4IbCE8WyPrOiu17mCDLqhGAuwdBFQLuNwud0PfGbnxvIo5LnQklGKl JjIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723480649; x=1724085449; 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=SUsnCibnMH7ivE2QYlQBgp1mKBBeANli3TzS8KQmWFE=; b=m21r4wh3BjJHKacLhUzoKr0P+KlRI6SIFsYAApqgarLcmpzwmwzre1GQOVx+rUupzh TjjtWWoQKedOkTOLxejCuHdQKTPuE/pq3MrJU03NTXqrvt6pvqYB7z2uAyMtbnkGUc15 uqRslwcjClvQ3sOuHxID1paeFEvdPKQEB3quxzkQnm5RFREIgf6nGA0TglAonElWcyam GKcScM16eAZclsvlS4OIEUsH0NVK6UILFrgbd8A8Om86X1aJVFEIG2k5j6Xix03TTxbD sNz5owCdLKZDFmsyDXBza0S+7wI2R6gJum9jYHKk4HmlbqEWEKVP8rqkdtMzootw6eep gfag== X-Gm-Message-State: AOJu0Yy5tl0lhT3JWGT+X6cUETGmX9bmmT6iR9JfXNLNjikIKErfBAaF gzLgYliS6gWpGr84h5WbpFc2jfHx4aECZgZCoFHl2WE4TFH+L+BJ6gR9ZcF7H/NAohRxitwvBP7 wxDcnRDdW6vmBEpf2PBnHmKGOWEQ= X-Google-Smtp-Source: AGHT+IGdkGRYMKPz6fGeWuviSa6r29Hq7C72Cwa/nAT+b5LQVA1xu/FZkI/NNG+zIvrFvV5rkZfmu4B90wRb95ClvZo= X-Received: by 2002:a05:6a21:6f01:b0:1c2:956a:a909 with SMTP id adf61e73a8af0-1c8d74e378bmr1009229637.27.1723480648815; Mon, 12 Aug 2024 09:37:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: semab tariq Date: Mon, 12 Aug 2024 21:37:17 +0500 Message-ID: Subject: Re: autovacuum freeze recommendations at table level To: Durgamahesh Manne Cc: pgsql-general@lists.postgresql.org, pgsql-in-general@postgresql.org, Christoph Berg Content-Type: multipart/alternative; boundary="000000000000d99e2a061f7f1b5b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d99e2a061f7f1b5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 triggered 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 this value can cause more frequent freezing, which can increase the overhead of 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 autovacu= um > 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_age= =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 > --000000000000d99e2a061f7f1b5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Durga

autovacuum_freeze_max_age=C2= =A0specifies the maximum age (in transactions) that a table's tuples ca= n reach before a vacuum is forced to prevent transaction ID wraparound. whe= n the age of the oldest tuple in the table exceeds this value, an autovacuu= m is triggered to freeze the tuples.
Recommendation =3D=C2=A02= 0000000 ->=C2=A0150000000=C2=A0

autovacuum_multixac= t_freeze_max_age It is=C2=A0similar to above, but applies to mul= ti-transaction IDs (used for shared row locks). when the age of the oldest = multi-transaction ID exceeds this value, an autovacuum is triggered to free= ze the multi-transaction IDs.
Recommendation =3D=C2=A020000000 ->= =C2=A0150000000

autovacuum_freeze_min_age
specifie= s the minimum age (in transactions) that a tuple must reach before it is co= nsidered for freezing. Lowering this value can cause more frequent freezing= , which can increase the overhead of autovacuum.
Recommend= ation =3D 0 ->=C2=A050000000

<= div>Thanks, Semab

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

Could you please=C2=A0let = me know that how this freeze parameters work
Update query runs on= table=C2=A0 through which data being modified daily in this case
Total records in table is about 20lakhs
current setting for this= =C2=A0table is=C2=A0
Access method: heap
if it reaches = > 0.1*2000000+1000 =3D 2,10,000 as per the formula autovacuum triggersOptions: fillfactor=3D85, autovacuum_vacuum_cost_delay=3D0, autovacuum_va= cuum_cost_limit=3D3000, parallel_workers=3D6, autovacuum_vacuum_scale_facto= r=3D0.1, autovacuum_vacuum_threshold=3D1000, autovacuum_freeze_max_age=3D20= 000000, autovacuum_multixact_freeze_max_age=3D20000000, autovacuum_freeze_m= in_age=3D0

How autovacuum freeze parameters wo= rk.Give me some recommendations to improve the performance better than now= =C2=A0
Ex :ALTER TABLE table SET (
=C2=A0 =C2=A0autovacuum_fre= eze_max_age =3D 20000000,(2 crores)
=C2=A0 =C2=A0autovacuum_multixact_fr= eeze_max_age =3D 20000000,(2 crores)
=C2=A0 =C2=A0autovacuum_freeze_min_= age =3D 0
);
Regards,
Durga Mahesh=C2=A0
--000000000000d99e2a061f7f1b5b--