From: | Anj Adu <fotographs(at)gmail(dot)com> |
---|---|
To: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: pg_attribute size |
Date: | 2009-10-26 21:29:19 |
Message-ID: | f2fd819a0910261429q1d21c203n8aa48e1bf68d315b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
We have several partitioned tables that get dropped every day ..We do
not do autovacuum as it is an IO hog (and most tables are dropped
anyways..and the large tables are never updated)..
I however did a plain vacuum analyze and that fixed the problem with
tools(e.g pgadmin) that accessed the data dictionary and were very
slow before the vacuum.
On Sun, Oct 25, 2009 at 9:41 PM, Steve Crawford
<scrawford(at)pinpointresearch(dot)com> wrote:
> Anj Adu wrote:
>>
>> I have a few databases where the size of pg_attribute > 6G.. This
>> keeps growing..
>>
>> is there a recommended way to purge data from this table.. Could this
>> also be why tools like pgAdmin take forever to open the database
>> browser?
>>
>>
>
> Do you have an extraordinary number of tables/columns?
>
> Try (as the database administrator), "vacuum full pg_attribute" perhaps
> followed by "reindex table pg_attribute". Be aware that this may pretty much
> lock your database while it is running. See if things improve then do as Tom
> says - make sure autovacuum is running.
>
> Cheers,
> Steve
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-10-26 22:46:43 | Re: pg_attribute size |
Previous Message | dinesh | 2009-10-26 21:13:55 | duplicate key violated errors |