|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||David Rowley <dgrowleyml(at)gmail(dot)com>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Reducing the chunk header sizes on all memory context types|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> Andres did mention to me off-list about perhaps adding a boolean field
> to FunctionCallInfoBaseData to indicate if the return value can be
> assumed to be in CurrentMemoryContext. I feel like that might be
> quite a bit of work to go and change all functions to ensure that
> that's properly populated.
That seems like the right basic answer, but wrong in detail. We have only
a tiny number of places that care about this --- aggregates and window
functions basically --- and those already have a bunch of special calling
conventions. So changing the generic fmgr APIs has side-effects far
beyond what's justified.
I think what we should look at is extending the aggregate/window
function APIs so that such functions can report where they put their
output, and then we can nuke MemoryContextContains(), with the
code code set up to assume that it has to copy if the called function
didn't report anything. The existing FunctionCallInfo.resultinfo
mechanism (cf. ReturnSetInfo for SRFs) is probably the right thing
to pass the flag through.
I can take a look at this once the release dust settles a little.
regards, tom lane
|Next Message||Nikita Glukhov||2022-10-03 19:44:27||Error-safe user functions|
|Previous Message||Jaime Casanova||2022-10-03 19:34:19||Re: pgsql: Avoid improbable PANIC during heap_update.|