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(at)Yahoo(dot)com #