Re: update on TOAST status'

Philip Warner wrote:
> At 14:02 11/07/00 +0200, Jan Wieck wrote:
> >    AFAICS, we need to detoast values for index  inserts  allways
> >    and  have  another toaster inside the index access methods at
> >    some day.
>
> We might not need it...at least not in the furst pass.

    The  thing  is  actually  broken  and needs a fix. As soon as
    "text" is toastable, it can happen everywhere  that  text  is
    toasted  even  if it's actual plain value would perfectly fit
    into an index tuple. Think of a table with 20  text  columns,
    where  the  indexed  one  has  a  1024 bytes value, while all
    others hold 512 bytes. In that case, the indexed one  is  the
    biggest  and  get's  toasted first. And if all the data is of
    nature that compression doesn't gain enough, it  might  still
    be the biggest one after that step and will be considered for
    move off ... boom.

    We can't let this in in the first pass!

> >    In the meantime we should decide  a  safe  maximum
> >    index tuple size and emit an explanative error message on the
> >    attempt to insert oversized index entries instead of possibly
> >    corrupting the index.
>
> Can I suggest that we also put out a warning when defining an index using a
> field with a (potentially) unlimited size? Indexing a text field will
> mostly be a bizarre thing to do, but, eg, indexing the first 255 chars of a
> text field (via substr) might not be.

    Marking it BOLD somewhere in the release  notes,  the  CREATE
    INDEX  doc  and  some  other  places should be enough. Such a
    message at every CREATE INDEX is annoying.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #