JanWieck@t-online.de (Jan Wieck) writes:
> Tom Lane wrote:
>> 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.
> I'm still argueing that indexing huge values is a hint for a
> misleading schema. If this is true, propagating toasted
> attributes into indices is a dead end street and I'd have to
> change the heap-access<->toaster interface so that the
> modified (stored) main tuple isn't visible to the following
> code (that does the index inserts).
But you'll notice that is *not* what I suggested. A detoasted-value
cache could be useful in more situations than just an index lookup.
I don't necessarily say we've got to have it in 7.1, but let's keep
the idea in mind in case we start finding there is a bottleneck here.
> What is the value of supporting index tuples >2K?
If you're toasting the whole main tuple down to <2K, you might find
yourself toasting individual fields that are a good bit less than
that. So I don't think indexing a toasted value will be all that
unusual.
But this is all speculation for now. Let's get it working bulletproof
for 7.1, and then worry about speedups after we know they are needed.
regards, tom lane
