MIME-Version: 1.0
References: 
 <CAHkYM9bmCEq8J=tUMYr6HRNL03ddUX3JUPCKY6frngBCbuPrGw@mail.gmail.com>
In-Reply-To: 
 <CAHkYM9bmCEq8J=tUMYr6HRNL03ddUX3JUPCKY6frngBCbuPrGw@mail.gmail.com>
From: Peter Geoghegan <pg@bowt.ie>
Date: Fri, 31 Jan 2025 17:45:48 -0500
Message-ID: 
 <CAH2-WzmZEQn7jH3iYZvsgMJ93Z=POaGcgu4BSF73_vSgoZUKcg@mail.gmail.com>
Subject: Re: High System CPU Usage on Selects Seemingly Caused By Vacuum of
 Same Table
To: Joshua Banton <bantonj@gmail.com>
Cc: pgsql-performance@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAH2-WzmZEQn7jH3iYZvsgMJ93Z%3DPOaGcgu4BSF73_vSgoZUKcg%40mail.gmail.com>
Precedence: bulk

On Fri, Jan 31, 2025 at 5:28=E2=80=AFPM Joshua Banton <bantonj@gmail.com> w=
rote:
> The issue mostly manifests near the end of the "scanning heap" phase of v=
acuuming of one of our largest tables, we'll call table1. RDS Performance I=
nsights reports that selects on table1 start to wait on cpu, where previous=
ly it didn't even show up in the top 25 queries by wait. It doesn't always =
happen, but if there is a larger than usual number of selects on table1 it =
is more likely to happen.

Does this database also have many tables? As in thousands of tables?

I am reminded of this issue:

https://www.postgresql.org/message-id/flat/da3205c4-5b07-a65c-6c26-a293c646=
4fdb%40postgrespro.ru

I've heard of this happening when an aggressive VACUUM updates
relfrozenxid on a larger table.

--=20
Peter Geoghegan