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


From: JanWieck(at)t-online(dot)de (Jan Wieck)
To: PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Applying TOAST to CURRENT
Date: 2000-05-29 15:03:10
Message-ID: 200005291503.RAA05644@hot.jw.home (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

    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?

    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?

    3.  Tom,  we  don't  have  a consensus how to merge the TOAST
        related function changes with the fmgr changes up to now.
        Which base type specific functions will be touched due to
        fmgr changes right now?



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


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2000-05-29 15:53:46
Subject: Vacuum now uses AccessShareLock for analyze
Previous:From: Karel ZakDate: 2000-05-29 14:57:04
Subject: Re: Berkeley DB...

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