Re: AW: update on TOAST status'

Zeugswetter Andreas SB wrote:
>
> > 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!
>
> Have you added a minimum size for a value to actually be considered
> for toasting ? Imho some lower border between 64 and 256 bytes per value
> would be useful, not only the row size.
>
> Imho the same logic should apply to choose wheather a fixed (max) size
> column
> qualifys for toasting (e.g. varchar(32) should never qualify for toasting)

The toaster simply tries to keep all heap tuples smaller than
2K (MaxTupleSize / 4). It does so by first compressing all
compressable ones, then moving off. Both steps allways pick
the attributes in descending size order.

It does not know anything about indices (and that wouldn't
help either because indices could be created later as done in
every dump).

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 #