Re: update on TOAST status

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 the value
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 try compression", "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's the 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 the parser
for 7.1, which will disappear in 7.2 again. If you
pg_dump/restore your databases during the 7.0->7.1 upgrade,
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(at)Yahoo(dot)com #