> 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
thatpassed 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))
isthere 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-memorytrees 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
