Re: Datum values consistency within one query

> On Apr 2, 2020, at 4:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> Paul Ramsey <pramsey@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