Well,
first I want to summarize some details, to see if we all
agree so far in the discussion.
- The implementation should be generic for all variable size
types, but can be enabled/disabled per type.
- Large values are moved out of the main tuple until it fit's
a yet to be defined size.
- The moved off values are kept in another relation per
table, using regular tuples where the value is split into
chunks. The new "expansion" relations get another relkind,
so they can be hidden from the user and the system can
easily identify them as such.
- The type specific functions call a central support function
to get the usual VARLENA format, which is taken from a LRU
cache or fetched from the extension relation. They are
responsible for freeing the memory after they're done with
the value. Some macro's should make it fairly simple to
handle.
I don't think it is a good idea to create the expansion
relation all the time. Some keyword in CREATE TABLE, and/or
another ALTER TABLE should do it instead, so the DB admin can
activate the LONG feature on a per table base as needed. In
the first implementation there will be no command to
deactivate it again. Workaround is rename table and select
into as usual.
Also I would like to say that system relations cannot have
expansion relations. At least not until we have enough
experience with this stuff.
Is that now what we initially want to give a try? If so, I
would like to start soon to get the generic part ready ASAP.
Others could then join in and contribute by adding LONG
support for all the VARLENA data types we have.
Would really be a big leap if we can get this finished for a
reasonable number of VARLENA types by February 1.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
