Re: more about pg_toast growth - Mailing list pgsql-general
From | Jeffrey W. Baker |
---|---|
Subject | Re: more about pg_toast growth |
Date | |
Msg-id | 1018380398.15250.30.camel@heat Whole thread Raw |
In response to | Re: more about pg_toast growth (Jan Wieck <janwieck@yahoo.com>) |
Responses |
Re: more about pg_toast growth
Re: more about pg_toast growth |
List | pgsql-general |
On Tue, 2002-04-09 at 11:52, Jan Wieck wrote: > Bruce Momjian wrote: > > > I doubled that, and it still doesn't work. You are suggesting I > > > increase your previous estimate by a factor of 200. Your email of > > > 2002-03-13 at 15:16 -0500 suggests a FSM of 50,000 pages allocates "some > > > more shared memory. It's surely in the range of a few megabytes..." > > > Will a FSM map 200 times larger require 200 times more memory, or is the > > > growth nonlinear? How can I calculate this requirement? Without some > > > documentation this database is inoperable. > > > > > > I stand behind my previous statement: if PostgreSQL's unchecked table > > > growth can only be prevented by changing an undocumented configuration > > > key using an undocumented formula producing undocumented system impact, > > > the implementation is flawed. > > > > This does bring up a point that VACUUM alone does not handle all cases > > of reusing tuple space. VACUUM FULL is needed occasionally. > > I still believe it's due to the massive amount of data pumped > through that table between vacuums and inappropriate settings > for the freespace map size for this particular case. > > Initially I suggested an FSM size of 50,000 "to start with". > That was meant as an introduction to play around with these > parameters a little, figuring out what the right settings are > in his case, and reporting back the result. What we got back > after a week or longer, was a lax "still doesn't work". It > seemed to me he had not spent alot of time to understand the > underlying concepts, nor has he ever taken a single look at > the code. I don't need this abuse. I'm perfectly capable of reading the source code for PostgreSQL. I helped diagnose a spinlock contention problem in the 7.2beta series and I maintain DBD::Pg. And I've contributed source code to several other projects which I need not list here. Surely I'd be willing to learn how to tune Pg, since I've staked my operation on it. But, "max_fsm_pages" produces fewer pages on Google than "deep fried orangutan pancreas", and I do not often have the time to leaf through 460,000 lines of source. Some documentation would be swell. -jwb
pgsql-general by date: