Re: Applying TOAST to CURRENT - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Applying TOAST to CURRENT |
Date | |
Msg-id | 200005300255.WAA17669@candle.pha.pa.us Whole thread Raw |
In response to | Applying TOAST to CURRENT (JanWieck@t-online.de (Jan Wieck)) |
Responses |
Re: Applying TOAST to CURRENT
|
List | 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@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
pgsql-hackers by date: