|From:||Paul Ramsey <pramsey(at)cleverelephant(dot)ca>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Datum values consistency within one query|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> On Apr 2, 2020, at 4:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Paul Ramsey <pramsey(at)cleverelephant(dot)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
> 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.
|Next Message||Corey Huinker||2020-04-03 17:34:17||Re: Add A Glossary|
|Previous Message||Tom Lane||2020-04-03 17:18:12||Re: [PATCH] Fix for slow GIN index queries when "gin_fuzzy_search_limit" setting is relatively small for large tables|