MIME-Version: 1.0
References: 
 <CAC5iy63HKROj55PSZ3Ls7WmXVWi-DvRaqqRpp_7A6g1QTPAb=Q@mail.gmail.com>
In-Reply-To: 
 <CAC5iy63HKROj55PSZ3Ls7WmXVWi-DvRaqqRpp_7A6g1QTPAb=Q@mail.gmail.com>
From: Siraj G <tosiraj.g@gmail.com>
Date: Fri, 17 Jan 2025 11:46:30 +0530
Message-ID: 
 <CAC5iy61AfsXXQ6F-Oz0hsV2kVPvu6OO61az9iUQ46eAFwaWbfQ@mail.gmail.com>
Subject: Re: vacuuming taking long time for pg_attribute
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000b7c614062be0dab5"
Archived-At: 
 <https://www.postgresql.org/message-id/CAC5iy61AfsXXQ6F-Oz0hsV2kVPvu6OO61az9iUQ46eAFwaWbfQ%40mail.gmail.com>
Precedence: bulk

--000000000000b7c614062be0dab5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

One other thing I would like to add..
While the performance was problem, our application jobs also failed and we
were unable to start them as internally they query pg_attribute.

Regards
Siraj

On Fri, Jan 17, 2025 at 11:45=E2=80=AFAM Siraj G <tosiraj.g@gmail.com> wrot=
e:

> Hello Experts!
>
> The PgSQL version is 16 and it runs in Cloud SQL managed by GCP.
>
> Problem was that we were unable to conveniently get the object details in
> the schema browser (within the Cloud SQL Studio) as it was getting timeou=
t
> again and again. Several application jobs start to fail. Eventually we
> found that pg_catalog.pg_attribute was having tons of dead tuples. While
> vacuum on this took several hours, the problem got resolved eventually.
> Command ran: vacuum pg_attribute;
>
> I would like to understand how this issue can be prevented. We do have
> autovacuum ON and I could see the last vacuum on this table was just abou=
t
> 30hrs back.
>
> Appreciate any suggestions.
>
> Regards
> Siraj
>

--000000000000b7c614062be0dab5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One other thing I would like to add..<div>While the perfor=
mance was problem, our application jobs also failed and we were unable to s=
tart them as internally they query pg_attribute.</div><div><br></div><div>R=
egards</div><div>Siraj</div></div><br><div class=3D"gmail_quote gmail_quote=
_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jan 17, 2025 at 1=
1:45=E2=80=AFAM Siraj G &lt;<a href=3D"mailto:tosiraj.g@gmail.com">tosiraj.=
g@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Hello Experts!<div><br></div><=
div>The PgSQL version is 16 and it runs in Cloud SQL managed by GCP.</div><=
div><br></div><div>Problem was that we were unable to conveniently=C2=A0get=
 the object details in the schema browser (within the Cloud SQL Studio) as =
it was getting timeout again and again. Several application jobs start to f=
ail. Eventually we found that pg_catalog.pg_attribute was having tons of de=
ad tuples. While vacuum on this took several hours, the problem got resolve=
d eventually.</div><div>Command ran: vacuum pg_attribute;</div><div><br></d=
iv><div>I would like to understand how this issue can be prevented. We do h=
ave autovacuum ON and I could see the last vacuum on this table was just ab=
out 30hrs back.=C2=A0</div><div><br></div><div>Appreciate any suggestions.<=
/div><div><br></div><div>Regards</div><div>Siraj</div></div>
</div>
</blockquote></div>

--000000000000b7c614062be0dab5--