Scott Marlowe wrote:
> 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.
>
Well, just to give you guys an idea of the size of db we're working with
(and, hopefully to make you postgres developers proud) a 'SELECT
COUNT(*) FROM pg_class;' returns a # over 300k for the # of relations in
the db. I really can't go too much furthur into that or the reason we
have so many due to my nda and such, but I'm sure you can see why this
has been such a big issue for me. Thanks again for all of your help,
and I'll be back soon with some questions regarding ANALYZE that I've
got cooking up in the back of my head...
--
erik jones <erik@myemma.com>
software development
emma(r)