Re: Free space mapping (was Re: Multi-Versions and Vacuum)

From: Mark Kirkwood <markir(at)slingshot(dot)co(dot)nz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Kirkwood <markir(at)slingshot(dot)co(dot)nz>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org, Andrew Sullivan <andrew(at)libertyrms(dot)info>
Subject: Re: Free space mapping (was Re: Multi-Versions and Vacuum)
Date: 2002-08-29 09:26:56
Message-ID: 3D6DE8E0.2090002@slingshot.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:

>It doesn't need a lot of examination in my mind: the cause is surely
>growth of the index on the toast table.
>
>
You are indeed correct !

A quick check of my test case shows that the toast table growth tails
off ( provided max_fsm_pages is suitably set), and the unbounded growth
comes entirely from the toast index.

Applying REINDEX brings the space usage down to a level that compares
with a non-toasted example.

With respect to the REINDEX workaround - having to re-start your server
single process for it is a bit fatal if you are 24/7 shop - I think
altering those high hit tables to have attributes detoasted might be
better (row length permitting).

Anyway that has *toasted* the need for my currrent little investigation
(quite enjoyed my romp through the code, so I am not too worried). I
still have some free time (I am off work after knee operation) so I'm
now looking for another project....

regards

Mark

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message jerome 2002-08-29 09:30:31 date_part???
Previous Message Nikhil G. Daddikar 2002-08-29 09:15:27 Deleting foreign key constraints