
> 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)

Andreas

Tue, 11 Jul 2000 16:25:22 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
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@Yahoo.com #



Tue, 11 Jul 2000 18:55:38 +0200 (MEST)
JanWieck@t-online.de (Jan Wieck)
Re: AW: update on TOAST status'