Re: Applying TOAST to CURRENT - Mailing 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