Re: Unbounded (Possibly) Database Size Increase - Toasting - Mailing list pgsql-hackers

From Manfred Koizar
Subject Re: Unbounded (Possibly) Database Size Increase - Toasting
Date
Msg-id 4qskeusivuafj3adqs5b64bego5q93kn0o@4ax.com
Whole thread Raw
In response to Re: Unbounded (Possibly) Database Size Increase - Toasting  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unbounded (Possibly) Database Size Increase - Toasting  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 21 May 2002 11:10:04 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>Odd.  I wonder whether you are looking at an unintended behavior of the
>free space map's thresholding mechanism.  The toast table will generally
>have large tuples of consistent size (about 2K each).

So we have 4 tuples per page?

>This will cause
>the FSM threshold for whether to remember a page to approach 2K, which
>probably will mean that we forget about pages that could still hold one
>toast tuple.

I thought I was able to follow you up to here.

>That might be enough to cause the growth.

Here I'm lost.  The effect you mention explains growth up to a state
where each toast table page holds 3 instead of 4 tuples (1.33 *
initial size).  Now with each UPDATE we get pages with significantly
more free space than 2K.  Even if we add a few 1.000 pages being added
before the next VACUUM, we still reach a stable size.  Of course this
only holds if there are enough FSM slots, which Mark claims to have.

So IMHO there have to be additional reasons causing *unbounded*
growth.  Or am I missing something?

Just my 0.02.
ServusManfred


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [GENERAL] Psql 7.2.1 Regress tests failed on RedHat 7.3
Next
From: Trond Eivind Glomsrød
Date:
Subject: Re: Redhat 7.3 time manipulation bug