From: | Jan Wieck <janwieck(at)yahoo(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org>, Jan Wieck <janwieck(at)yahoo(dot)com>, Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: more about pg_toast growth |
Date: | 2002-04-09 18:52:17 |
Message-ID: | 200204091852.g39IqIl02325@saturn.janwieck.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 #
From | Date | Subject | |
---|---|---|---|
Next Message | Ed Loehr | 2002-04-09 18:57:57 | Re: Hash Join vs Nested Loops in 7.2.1 ... |
Previous Message | Papp, Gyozo | 2002-04-09 18:22:57 | Re: SPI_execp() failed in RI_FKey_cascade_del() |