Re: more about pg_toast growth

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