Re: more about pg_toast growth

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. Pumping multiple  gigabytes  every  day  through  a
    database is not the occational DB usage, where you can expect
    default settings to be appropriate. This is  clearly  a  case
    where  someone has to "learn" the finer details about tuning.

    This is an open source project.  Getting that pi**ed about my
    response, and asking that snobby for URL's to the appropriate
    documentation, finally telling "this database is inoperable",
    well,  maybe  he's  better  off  with  a support contract for
    Oracle or SQL-Server.  At  least  he'll  not  get  any  picky
    comments from those people.

    I  will  look  into  it another day, but without someone else
    running into the same problem, I  don't  feel  much  pressure
    doing so right now.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #