Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> - VACUUM doesn't propagate ANALYZE to TOAST tables.
>> Statistics for them are needless because the toast access
>> is allways hardcoded indexed.
> I don't think statistics are insignificant for TOASTed columns.
He didn't say that! I think what he meant is that there's no need for
statistics associated with the TOAST table itself, and AFAICS that's OK.
BTW, I have thought of a potential problem with indexes on toasted
columns. As I understand Jan's current thinking, the idea is
1. During storage of the tuple in the main table, any oversize fields
get compressed/moved off.
2. The toasted item in the finished main tuple gets handed to the index
routines to be stored in the index.
Now, storing the toasted item in the index tuple seems fine, but what
I do not like here is the implication that all the comparisons needed
to find where to *put* the index tuple are done using a pretoasted
value. That seems to imply dozens of redundant decompressions/fetches,
another one for each key comparison we have to do.
Jan, do you have a way around this that I missed?
One simple answer that might help for other scenarios too is to keep
a small cache of the last few values that had to be untoasted. Maybe
we only need it for moved-off values --- it could be that decompression
is fast enough that we should just do it over rather than trying to
cache.
regards, tom lane