On Wed, 2002-05-22 at 03:10, Tom Lane wrote:
> (snippage) That might be enough to cause the growth. It may be
> worth playing around with the details of the threshold-setting policy.
>
(snippage)
> Possibly the initial threshold set in create_fsm_rel also needs to be
> smaller than it is. Not
Manfred Koizar <[EMAIL PROTECTED]> writes:
> 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.
Good point, it shou
On Tue, 21 May 2002 11:10:04 -0400, Tom Lane <[EMAIL PROTECTED]>
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
<[EMAIL PROTECTED]> writes:
> The toast table gets about 90 percent of the growth, followed by the toast
> index at about 9 percent. The actual table + primary key stay at about 2M each.
Odd. I wonder whether you are looking at an unintended behavior of the
free space map's thresholding mechani
>
> Hmm. Which file(s) were growing, exactly? How many row updates is this
> run covering?
>
The toast table gets about 90 percent of the growth, followed by the toast
index at about 9 percent. The actual table + primary key stay at about 2M each.
I neglected to mention what the update stat
Hannu Krosing <[EMAIL PROTECTED]> writes:
> But does PG not have a new index entry for each _version_ of table row ?
Sure, but the entries do go away during vacuum.
> Or does lack-of-btree-collapse-logic affect only keys where there are
> many _different_ keys and not many repeating keys?
The p
On Mon, 2002-05-20 at 16:08, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Sun, 2002-05-19 at 19:37, Tom Lane wrote:
> >> I'd rather expect the toast indexes to grow given the lack-of-btree-
> >> collapse-logic issue.
>
> > Why sould the toast indexes grow significantly more
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Sun, 2002-05-19 at 19:37, Tom Lane wrote:
>> I'd rather expect the toast indexes to grow given the lack-of-btree-
>> collapse-logic issue.
> Why sould the toast indexes grow significantly more than the primary key
> of main table ?
Well, the toast
On Sun, 2002-05-19 at 19:37, Tom Lane wrote:
> Mark kirkwood <[EMAIL PROTECTED]> writes:
> > However I could not get any size stabilization in the toasted case.
>
> Hmm. Which file(s) were growing, exactly? How many row updates is this
> run covering?
>
> I'd rather expect the toast indexes to
Mark kirkwood <[EMAIL PROTECTED]> writes:
> However I could not get any size stabilization in the toasted case.
Hmm. Which file(s) were growing, exactly? How many row updates is this
run covering?
I'd rather expect the toast indexes to grow given the lack-of-btree-
collapse-logic issue. Howev
On Sat, 2002-05-11 at 11:24, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Was it not the case that lazy vacuum had problems freeing tuples that
> > have toasted fields ?
>
> News to me if so.
>
> regards, tom lane
It looks like this may in fact be the ca
11 matches
Mail list logo
