=?ISO-8859-1?Q?Jorge_Ar=E9valo?= <jorge.arevalo@deimos-space.com> 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
