Re: Long running query causing XID limit breach - Mailing list pgsql-general

From sud
Subject Re: Long running query causing XID limit breach
Date
Msg-id CAD=mzVXm2wQD707KrwsQUH=8xE3Zknr8hWuTV_qz2XcTzFzYXg@mail.gmail.com
Whole thread Raw
In response to Re: Long running query causing XID limit breach  (Muhammad Salahuddin Manzoor <salahuddin.m@bitnine.net>)
Responses Re: Long running query causing XID limit breach
List pgsql-general
On Thu, May 23, 2024 at 9:00 AM Muhammad Salahuddin Manzoor <salahuddin.m@bitnine.net> wrote:
Greetings,

In high-transaction environments like yours, it may be necessary to supplement this with manual vacuuming.

Few Recommendations

Monitor Long-Running Queries try to optimize.
Optimize Autovacuum.
Partitioning.
Adopt Vacuum Strategy after peak hours.

We have these big tables already partitioned. So does "vacuum table_name" will endup scanning whole table or just the latest/live partition which is getting loaded currently? and do you mean to say running command "vacuum table_name;" frequently on selective tables that are experiencing heavy DML ? Hope this won't lock the table anyway because the data will be written/read from these tables 24/7.

When you say, "optimize autovacuum" does it mean to set a higher value of "autovacuum_max_workers" and "autovacuum_freeze_max_age"?

Considering we have ~4 billion rows inserted daily into the table and there is limit of ~2billion to the "Maximumusedtxnids", what threshold should we set for the alerting and to have enough time at hand to fix this issue?

pgsql-general by date:

Previous
From: Muhammad Salahuddin Manzoor
Date:
Subject: Re: Json table/column design question
Next
From: Muhammad Salahuddin Manzoor
Date:
Subject: Re: Long running query causing XID limit breach