From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | Erik Jones <erik(at)myemma(dot)com> |
Cc: | pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Impact of vacuum full... |
Date: | 2006-07-21 20:56:30 |
Message-ID: | 1153515390.31664.30.camel@state.g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 2006-07-21 at 15:49, Erik Jones wrote:
> Scott Marlowe wrote:
> >
> > I'd use regular cronned vacuums on the tables that you know grown a lot
> > (or just hit the whole db and not worry about it) and run occasional
> > vacuum verbose / vacuum full verbose by hand to see if you have problems
> > with your Free Space Map being too small.
> >
> Awesome! Thanks, guys, for all of your input/advice. That's pretty
> much how I thought stuff worked after reading the docs but was
> confused/misled by other inputs. With regards to the Free Space Map and
> max_fsm_relations: is using the value of "SELECT COUNT(*) FROM
> pg_class;" plus some room for growth a good way to set that?
I always use vacuum verbose to see that. At the end, it'll have a part
that looks like this:
INFO: free space map: 35 relations, 18903 pages stored; 17504 total
pages needed
DETAIL: Allocated FSM size: 5000 relations + 100000 pages = 894 kB
shared memory.
VACUUM
So, on this machine, we can handle 5000 relations of 100,000 total
pages, and we're only uses the space of 35 relations and ~20,000 pages.
If the pages needed exceeds the allocated size, you've got problems.
You've got to run the database for a while to see what the state will be
like over time.
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Jones | 2006-07-21 21:14:28 | Re: Impact of vacuum full... |
Previous Message | Erik Jones | 2006-07-21 20:49:02 | Re: Impact of vacuum full... |