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
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 |