Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> But we can resolve that by ruling that the required lifetime is the same
>> as the value would have had if it'd really been palloc'd --- IOW, until
>> the memory context that was current at the time gets deleted or reset.
> Many support functions of GiST/GIN live in very short memory context - only
> for
> one call. So, that cache invalidation technique doesn't give any advantage
> without rearranging this part.
Right, but I think I've got that covered. The memory context reset
won't actually flush the toast cache entry, it effectively just drops its
reference count. We'll only drop cache entries when under memory
pressure (or if they're invalidated by toast table updates/deletes).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
