Re: Unbounded (Possibly) Database Size Increase - Toasting

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: markir(at)slingshot(dot)co(dot)nz, Hannu Krosing <hannu(at)tm(dot)ee>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Unbounded (Possibly) Database Size Increase - Toasting
Date: 2002-05-21 16:48:53
Message-ID: 4qskeusivuafj3adqs5b64bego5q93kn0o@4ax.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 21 May 2002 11:10:04 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
Servus
Manfred

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-05-21 17:06:56 Re: Unbounded (Possibly) Database Size Increase - Toasting
Previous Message Tom Lane 2002-05-21 16:48:39 Killing dead index tuples before they get vacuumed