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

Re: Applying TOAST to CURRENT

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Applying TOAST to CURRENT
Date: 2000-05-30 14:42:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Bruce Momjian wrote:
> > >         OTOH  I  don't  think  it's  a good thing to try creating
> > >         these things on  the  fly  the  first  time  needed.  The
> > >         required catalog changes and file creations introduce all
> > >         kinds of possible rollback/crash problems, that we  don't
> > >         want to have here - do we?
> >
> > Well, we could print the message suggesing ALTER TABLE when printing
> > tuple too large.  Frankly, I don't see a problem in creating the backup
> > table automatically.  If you are worried about performance, how about
> > putting it in a subdirectory.
>     It's  the toast-table and the index. So it's 2 Inodes and 16K
>     per table.  If the backend is compiled with -g, someone needs
>     to create about 500 tables to waste the same amount of space.
>     Well, I like the subdirectory idea. I only  wonder  how  that
>     should be implemented (actually the tablename is the filename
>     - and that doesn't allow / in it).

Not sure.  It will take some tricks, I am sure.   How about if we add
some TOAST option to CREATE TABLE, so they can create with TOAST support
rather than having to use ALTER every time.  Maybe that would work.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-05-30 14:44:59
Subject: Re: 7.0 weirdness
Previous:From: Matthias UrlichsDate: 2000-05-30 14:31:35
Subject: Re: [HACKERS] Re: 7.0 weirdness

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