From: | Siraj G <tosiraj(dot)g(at)gmail(dot)com> |
---|---|
To: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: size of attributes table is too big |
Date: | 2025-03-25 04:36:22 |
Message-ID: | CAC5iy61UBi3gQh3bWL0f13Ouxg7BgKDbASscpy1whzr7c=ZkDw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 Johnson <ronljohnsonjr(at)gmail(dot)com>
wrote:
> On Wed, Mar 19, 2025 at 1:06 PM Siraj G <tosiraj(dot)g(at)gmail(dot)com> 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 GB
>> pg_attribute_relid_attnam_index
>> 117 GB
>> pg_attribute_relid_attnum_index
>> 69 GB
>>
>> I think this table must have tons of dead tuples. Please suggest to me if
>> we can purge any data/shrink the size of this table.
>>
>>
> Run pgstattuple and pgstatindex on them. They'll tell you how much bloat
> you have.
>
> And tune your autovacuum parameters to be more aggressive. These, for
> example, are my settings:
> autovacuum_analyze_scale_factor = 0.015
> autovacuum_vacuum_scale_factor = 0.015
> autovacuum_vacuum_insert_scale_factor = 0.015
> autovacuum_vacuum_insert_threshold = 250
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2025-03-25 05:09:07 | Re: query_id: jumble names of temp tables for better pg_stat_statement UX |
Previous Message | Tom Lane | 2025-03-25 04:32:05 | Re: query_id: jumble names of temp tables for better pg_stat_statement UX |