Re: Unbounded (Possibly) Database Size Increase - Toasting

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark kirkwood <markir(at)slingshot(dot)co(dot)nz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Unbounded (Possibly) Database Size Increase - Toasting
Date: 2002-05-20 15:39:28
Message-ID: 1021909168.14280.285.camel@taru.tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2002-05-20 at 16:08, Tom Lane wrote:
> Hannu Krosing <hannu(at)tm(dot)ee> 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 indexes will grow because they're using an OID key,
> and so the range of indexed values keeps increasing. AFAIR Mark didn't
> say whether he *had* a primary key, let alone what it was --- but it's
> possible that he has one that has a range that's not changing over the
> test.

his table is this:

CREATE TABLE grow (id integer,body text,CONSTRAINT grow_pk PRIMARY KEY (id))
> In particular, if the test consists simply of updating the toasted
> field, that will not change the primary keys at all ... but it will
> change the toast table's key range, because each new value will get
> a new toast OID.

But does PG not have a new index entry for each _version_ of table row ?

Or does lack-of-btree-collapse-logic affect only keys where there are
many _different_ keys and not many repeating keys?

--------------
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bear Giles 2002-05-20 15:46:33 more on makecert and pgkeygen
Previous Message Tom Lane 2002-05-20 15:25:31 timestamp-to-date broken in current sources