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(at)Yahoo(dot)com #