Skip site navigation (1) Skip section navigation (2)

Re: [ADMIN] Excessive growth of pg_attribute and other system tables

From: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [ADMIN] Excessive growth of pg_attribute and other system tables
Date: 2005-04-01 01:50:49
Message-ID: d2i9fa$26n5$ (view raw, whole thread or download thread mbox)
Lists: pgsql-adminpgsql-hackers
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes
> Steve Crawford <scrawford(at)pinpointresearch(dot)com> writes:
> > On Monday 21 March 2005 11:40 am, Tom Lane wrote:
> >> However, given that there are 9334 tuples in 82282 pages, I'd say
> >> that autovacuum has already failed Steve rather badly :-(.  There
> >> shouldn't be more than a couple hundred pages given that number of
> >> rows.  Perhaps the FSM settings are too small?

Seems this is another question pointing to the inproper setting of
"can-be-avoided" shared memory parameters. Maybe we should eliminate GUC
parameters related to the FSM. Can we follow Alvaro's idea like spilling
some data of FSM into disk while keeping the indices and maybe part of data
in the memory? So no free page would be discarded due to no space to record
them in FSM? Also, in this handling, efficiency should not be a problem.


In response to

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2005-04-01 02:22:33
Subject: Re: Bug in DROP NOT NULL
Previous:From: Alvaro HerreraDate: 2005-04-01 01:31:14
Subject: Re: Debugging deadlocks

pgsql-admin by date

Next:From: Shashi GireddyDate: 2005-04-01 02:44:40
Subject: Re: initdb.exe error while installing postgres 8.0
Previous:From: Joshua D. DrakeDate: 2005-04-01 00:33:31
Subject: Re: getGeneratedKeys()

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group