I am guessing the analyze helped the pgadmin data-dictionary query
planning..The vacuum will help with space re-use. the size is not
smaller as I did not do a vacuum full.
On Mon, Oct 26, 2009 at 4:27 PM, Scott Marlowe wrote:
> On Mon, Oct 26, 2009 at 3:29 PM, Anj Adu wrote:
>> We have several
On Mon, Oct 26, 2009 at 3:29 PM, Anj Adu wrote:
> 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)..
1: autovac can be adjusted to use much less IO than regu
We dump and vacuum every database every evening, so we can control
when the vacuums occur.
How does one vacuum the system catalogs? By each tablename pg_*?
Thanks,
Naomi
>
> On Mon, Oct 26, 2009 at 3:46 PM, Tom Lane wrote:
>> Anj Adu writes:
>>> We have several partitioned tables that get dr
Agreed...
Thank you
On Mon, Oct 26, 2009 at 3:46 PM, Tom Lane wrote:
> Anj Adu writes:
>> 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)..
>
> If you'
Anj Adu writes:
> 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)..
If you're not going to run autovacuum then that means *you* must take
responsibility for
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
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/c
Anj Adu writes:
> I have a few databases where the size of pg_attribute > 6G..This
> keeps growing..
Have you got autovacuum disabled? That should keep the bloat in check
if it's allowed to work normally.
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsq
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?
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
T
