=?ISO-8859-1?Q?Jorge_Ar=E9valo?= <jorge.arevalo@xxxxxxxxxxxxxxxx> writes: > Interesting. I've read the README document at src/backend/utils/mmgr, > and I have some unclear points yet: > I've understood several well-known memory contexts exist > (TopMemoryContext, CacheMemoryContext, MessageContext, > CurTransactionContext...), but I don't know what memory context are > more important for the creator of a new SQL function. 99% of functions never touch any of those top-level contexts. Usually you use the call-time CurrentMemoryContext for anything that only needs to live as long as the function runs, and for anything you intend to return as the function result. If you want to cache something across calls within a query, you store it in fn_mcxt or multi_call_memory_ctx. There's seldom a good reason to do anything else. > - The one pointed by fcinfo->flinfo->fn_mcxt. It has query-cycle > persistence, you said. > - The one pointed by funcctx->multi_call_memory_ctx, in SRF. With > query-cycle persistence too, I suppose. > What's the difference between both? Not much --- in fact, I'd bet they're usually the same context. It's a matter of which API you're using. If you're using flinfo->fn_extra to hold a pointer to some cached data, you should put that cached data in fn_mcxt. If you're relying on the funcapi.h SRF support macros, it's better to reference multi_call_memory_ctx; touching fn_mcxt directly would be a violation of the SRF abstraction layer. > And another question: what's the difference between tuple-cycle and > query-cycle lifespan? In case of functions returning several rows > (SRF), I see it clear. But in case of functions returning single > values, or single rows, I can't see it. If you have say select concat(txt1, txt2) from table ... the result of the concat needs to be delivered in a tuple-cycle memory context, else you'll have a leak across the rows of the table. But if the function wanted to stash some information to avoid looking it up again during each call, it'd need to put that in a query-lifespan memory context. There actually isn't any such thing as a context that's automatically reset at the end of each individual function call (although some particularly memory-hungry functions choose to implement one for themselves). The reason is that for example in select concat(txt1, txt2), concat(txt3, txt4) from table ... both function results have to stick around until we form the result tuple at the end of evaluating the SELECT list. So we only reset the context at the end of the tuple cycle, not after each function. This means that any internal allocations that a function neglects to pfree are "leaked" till the end of the tuple cycle, but that's almost never worth worrying about. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
