> 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