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 02:55:02
Message-ID: 200005300255.WAA17669@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Hi,
>
> now that we have the branch for 7.0, I could apply my actual
> work on TOAST to the CURRENT development tree. Before doing
> so, I'd like to discuss some related details.
>
> 1. In the actual version, the lztext datatype is stripped
> down to something more similar to text (does not compress
> on input). So it is kinda toastable base type for testing
> purposes created at initdb time.
>
> The pg_rules catalog still uses it, just that the toaster
> is now responsible to do the compression work. No
> problems so far with that.
>
> In the long run I think lztext will disappear completely
> again (it was supposed to be). Does anybody see a problem
> with abuse of this type during development?

Sounds fine.

> 2. I've added another ALTER TABLE command to create the
> external storage table for a relation. The syntax is
>
> ALTER TABLE tablename CREATE TOAST TABLE;
>
> Up to that, toastable types (lztext only yet) will be
> compressed, but the INSERT still fails if compression
> isn't enough to make a tuple fit.
>
> We haven't decided yet how/when to create the secondary
> relation and it's index. Since we intend to make base
> types like text and varchar by default toastable, I don't
> think that "if a tables schema contains toastable types"
> is a good enough reason to create them silently. There
> might exists tons of tables in a schema, that don't
> require it.
>
> 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.

--
Bruce Momjian | http://www.op.net/~candle
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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-05-30 05:49:55 Re: Full text indexing preformance! (long)
Previous Message Bruce Momjian 2000-05-30 02:42:07 Re: #include cleanup