Jeffery Collins wrote:
> Jan Wieck wrote:
>
> > FYI,
> >
> > For now, "lztext" is the only test candidate datatype to
> > invoke the toaster. It can hold up to multi-megabytes now.
> > But be warned, this datatype will disappear as soon as "text"
> > is toastable.
> >
>
> I have not been following the TOAST discussion, but why would lztext
> disappear? It seems like a useful datatype independent of TOAST or not
> TOAST?
The "lztext" type was something I developed before TOAST was born. It's was a "text" type that tried to compress
thevalue at input time.
In the TOAST world, each input value will be passed around as is. Only when it gets down to be stored in a table
and the resulting heap tuple exceeds 2K, the toaster will try to compress toastable attributes and/or move off
attributes.The behaviour will be configurable on a per tables attribute base. So someone can specify "don't
trycompression", "ignore this attribute until all others are toasted" or "never toast this, instead fail and abort
-unwise but possible".
In the current CVS sources, "lztext" already doesn't know anything about compression anymore. It's more
or less equivalent to "text" now, where it's lztextin() function produces a plain varlena structure like
textin()does. Only that all it's other functions are aware that the values they recieve might be toasted ones.
It'sthe toaster that does the compression/move-off for it now.
So as soon as "text" is toastable, there is absolutely no need for "lztext" anymore. We will add an alias to
theparser for 7.1, which will disappear in 7.2 again. If you pg_dump/restore your databases during the
7.0->7.1upgrade, all your table schemas will automatically be changed from "lztext" to "text".
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
