Skip site navigation (1) Skip section navigation (2)

Re: Applying TOAST to CURRENT

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Applying TOAST to CURRENT
Date: 2000-05-30 19:03:22
Message-ID: 3934107A.37BE2A6D@tm.ee (view raw or flat)
Thread:
Lists: pgsql-hackers
The Hermit Hacker wrote:
> 
> On Tue, 30 May 2000, Tom Lane wrote:
> >
> > I agree with Bruce --- the toast table should be created automatically,
> > at least if the table contains any potentially-toastable columns.  We
> > want this to be as transparent as possible.  I'd rather have auto create
> > on-the-fly when first needed, but if that seems too risky then let's
> > just make the table when its owning table is created.
> 
> have to third this one ... I think it should be totally transparent to the
> admin/user ... just create it when the table is created, what's the worst
> case scenario?  it never gets used and you waste 16k of disk space?

You dont even use 16k if toast tables are like ordinary tables (which I 
guess they are). New empty tables seem to occupy 0k.

So I'm also for immediate creation of tost tables for all tables that 
require them, either at create (if there are any toastable columns in 
the create clause) or at alter table time if first toestable column is 
added after initial create.

The only drawback is bloating directories, but it was already suggested
that 
TOAST tables could/should be kept in subdirectory toast (as should
indexes 
too, imho).

And the most widespread database in the world does it too ;) 
(dBASE and its derivates)

--------
Hannu

In response to

Responses

pgsql-hackers by date

Next:From: Krotenko Valery V.Date: 2000-05-30 19:38:11
Subject: RE: New Type
Previous:From: Bruce MomjianDate: 2000-05-30 18:20:46
Subject: Mention WAL in the book

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group