AW: AW: update on TOAST status'

>     The  actual  behaviour  of the toaster is to toast each tuple
>     until it has a delicious looking, brown and  crispy  surface.
>     The  indicator  for  beeing delicious is that it shrank below
>     MaxTupleSize/4 - that's a little less than 2K in a default 8K
>     blocksize setup.

>     So the indices simply inherit the toasting result. If a value
>     got  compressed,  the index will store the compressed format.
>     If it got moved off, the index  will  hold  the  toast  entry
>     reference for it.

Ok, this is where I would probably rethink the behavior.
Would it be possible to choose which columns need to 
stay "moved off" in the index on the basis that the key size stays 
below page size / 4 ? Thus if a key fits inside the 2k
you don't store the reference, but the compressed values
(even if they stay moved off for the heap table).

The timings you did only involved heap tuples not index. 
My guess would be, that there is a similar tradeoff in the index.
Fetching toast values for header pages in an index seems like 
a very expensive operation, because it needs to be performed for
every index access even if the searched value is not toasted
but falls into this range.

Of course this does not solve the "toast value" for key already 
deleted, but it would lower the probability somewhat.

Andreas