> On Apr 2, 2020, at 4:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Paul Ramsey <pram...@cleverelephant.ca> writes:
>> Getting the datum value is really fast, so I can have a cache that
>> keeps the latest detoasted object around, and update it when the datum
>> changes, and store the cache information in the parent context. Like
>> so:
>
> Jeez, no, not like that. You're just testing a pointer.
> ...
> The case where this would actually be worth doing, probably, is where
> you are receiving a toasted-out-of-line datum. In that case you could
> legitimately use the toast pointer ID values (va_valueid + va_toastrelid)
> as a lookup key for a cache, as long as it had a lifespan of a statement
> or less. You'd have to get a bit in bed with the details of toast
> pointers, but it's not like those are going anywhere.
So, if I tested for VARATT_IS_EXTENDED(), and then for
VARATT_IS_EXTERNAL_ONDISK(attr) and then did
VARATT_EXTERNAL_GET_POINTER(toast_pointer, attr), I could use va_valueid +
va_toastrelid as keys in the cache for things that passed that filter?
What about large const values that haven't been stored in a table yet? (eg,
ST_Buffer(ST_MakePoint(0, 0), 100, 10000)) is there a stable key I can use for
them?
> It would be interesting to tie that into the "expanded object"
> infrastructure, perhaps, especially if the contents of the objects
> you're interested in aren't just flat blobs of data.
Yeah, I'm wrestling with the right place to do this stuff, it's not just the
detoasting going on, I also build in-memory trees on large objects and hold
them around for as long as the object keeps showing repeatedly up in the query,
I just test the cache right now by using memcmp on the previous value and
that's really pricey.
P
