From: | sud <suds1434(at)gmail(dot)com> |
---|---|
To: | Muhammad Salahuddin Manzoor <salahuddin(dot)m(at)bitnine(dot)net> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Long running query causing XID limit breach |
Date: | 2024-05-23 04:48:39 |
Message-ID: | CAD=mzVXm2wQD707KrwsQUH=8xE3Zknr8hWuTV_qz2XcTzFzYXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, May 23, 2024 at 9:00 AM Muhammad Salahuddin Manzoor <
salahuddin(dot)m(at)bitnine(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Muhammad Salahuddin Manzoor | 2024-05-23 05:12:08 | Re: Long running query causing XID limit breach |
Previous Message | Muhammad Salahuddin Manzoor | 2024-05-23 04:01:16 | Re: Json table/column design question |