On Sunday, November 24, 2013 at 4:42 PM, Tom Lane wrote: > The real question of course is whether transaction-level caching is > appropriate for what they're storing. If they want only statement-level > caching then using fn_extra is often the right thing.
I'm not certain it is... we get some great effects out of the statement level stuff, and it really works great except for those cases where somebody else is already taking the slot (SRF_*) > Also note that having the cache go away is the easy part. The hard part > is knowing whether you've created it yet in the current transaction, and > finding it if you have. The usual method is to keep a static variable > pointing to it, and plugging into the transaction cleanup callback > mechanism with a routine that'll reset the pointer to NULL at transaction > end. For examples, look for callers of RegisterXactCallback(). > I'm glad you said that, because I felt too stoopid to ask :) my previous spelunking through memory contexts showed that it's easy to get the memory, hard to find it again. Which is why fn_extra is so appealing, it's just sitting there, and the parent context goes away at the end of the query, so it's wonderfully simple to use... if there's not already someone in it. Thanks for the advice, it could be very helpful for my pointcloud work, since having access to a cache object during SRF_* stuff could improve performance quite a bit, so the complexity trade-off of using the transactional context could be well worth it. P. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
