Re: more about pg_toast growth

From: "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org>
To: Postgres general mailing list <pgsql-general(at)postgresql(dot)org>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: more about pg_toast growth
Date: 2002-04-09 19:26:38
Message-ID: 1018380398.15250.30.camel@heat
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2002-04-09 19:37:23 Re: numeric test on RiscPC
Previous Message Grant Johnson 2002-04-09 19:11:48 MDDB/MOLAP