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@Yahoo.com #