Use "pg_repack" instead. It's an "online" CLUSTER / VACUUM FULL
replacement that's in both RPM and apt repos.
On Tue, Mar 25, 2025 at 12:36 AM Siraj G wrote:
> Thank you!
>
> I noticed over 99% free space. Now the challenge is running FULL VACUUM on
> a table with size over 500GB. It is going t
Thank you!
I noticed over 99% free space. Now the challenge is running FULL VACUUM on
a table with size over 500GB. It is going to take a couple of hours I
presume.
Also, I hope aggressive vacuuming will prevent us from this situation.
Regards
Siraj
On Wed, Mar 19, 2025 at 11:27 PM Ron Johns
Hello Pavel
The SQL instance is a target of google DMS and it does have a physical
replica.
A couple of weeks back we did have a performance issue and vacuum was run
at that time to fix the problem. Very soon we may run into the same problem
I presume.
Regards
Siraj
On Wed, Mar 19, 2025 at 10:4
On Wed, Mar 19, 2025 at 1:06 PM Siraj G wrote:
> Hello!
>
> I have a PG (v16) instance which is occupying around 1TB of storage. Out
> of this, around 350GB is occupied by the table pg_catalog.pg_attribute.
> Why is the catalog table's size so big?
>
> Here are the sizes:
>
> pg_attribute
> 338 G
Hi Adrian
Used this query to find the sizes:
select relname AS object_name,relkind AS
object_type,pg_size_pretty(pg_relation_size(oid)) AS object_size
FROM pg_class WHERE relnamespace = (SELECT oid FROM pg_namespace WHERE
nspname = 'pg_catalog')
ORDER BY pg_relation_size(oid) DESC;
We have clos
On 3/19/25 10:36 AM, Siraj G wrote:
Hi Adrian
Used this query to find the sizes:
select relname AS object_name,relkind AS
object_type,pg_size_pretty(pg_relation_size(oid)) AS object_size
FROM pg_class WHERE relnamespace = (SELECT oid FROM pg_namespace WHERE
nspname = 'pg_catalog')
ORDER
st 19. 3. 2025 v 18:14 odesílatel Álvaro Herrera
napsal:
> Hello
>
> On 2025-Mar-19, Siraj G wrote:
>
> > I have a PG (v16) instance which is occupying around 1TB of storage. Out
> of
> > this, around 350GB is occupied by the table pg_catalog.pg_attribute.
> > Why is the catalog table's size so b
On 3/19/25 10:06, Siraj G wrote:
Hello!
I have a PG (v16) instance which is occupying around 1TB of storage. Out
Exact version of Postgres 16, include the x in 16.x.
of this, around 350GB is occupied by the table pg_catalog.pg_attribute.
Why is the catalog table's size so big?
Here are the
Hello
On 2025-Mar-19, Siraj G wrote:
> I have a PG (v16) instance which is occupying around 1TB of storage. Out of
> this, around 350GB is occupied by the table pg_catalog.pg_attribute.
> Why is the catalog table's size so big?
Heavy use of temp tables is a known cause of this.
> I think this t
