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
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 Momjian||Date: 2000-05-29 15:53:46|
|Subject: Vacuum now uses AccessShareLock for analyze|
|Previous:||From: Karel Zak||Date: 2000-05-29 14:57:04|
|Subject: Re: Berkeley DB...|