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
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
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: