Applying TOAST to CURRENT - Mailing list pgsql-hackers

From JanWieck@t-online.de (Jan Wieck)
Subject Applying TOAST to CURRENT
Date
Msg-id 200005291503.RAA05644@hot.jw.home
Whole thread Raw
Responses Re: Applying TOAST to CURRENT  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Applying TOAST to CURRENT  (Tom Lane <tgl@sss.pgh.pa.us>)
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
aproblem       with abuse of this type during development?
 
   2.  I've added another ALTER  TABLE  command  to  create  the       external storage table for a relation. The
syntaxis
 
           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?
 
   3.  Tom,  we  don't  have  a consensus how to merge the TOAST       related function changes with the fmgr changes
upto now.       Which base type specific functions will be touched due to       fmgr changes right now?
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #




pgsql-hackers by date:

Previous
From: Kovacs Zoltan
Date:
Subject: Re: ODBC patch
Next
From: Lamar Owen
Date:
Subject: Re: #include cleanup