so 19. 7. 2025 v 5:08 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
"David G. Johnston" <david.g.johnston@gmail.com> writes: > On Sunday, July 6, 2025, Paul Jungwirth <pj@illuminatedcomputing.com> wrote: >> The second patch adds a new <sect2> explaining how we inline SQL >> functions: both single-result and set-returning. Since this happens >> automatically, it makes a nice progression with the (easy) declarative >> annotations and the (hard) support functions.
> The fact that attaching a set clause to the function definition (i.e., > proconfig) prevents inlining is missing from this description.
TBH, I think trying to document this behavior at this level of detail will be a disaster. Our track record for keeping documentation in sync with code is awful, and what exactly will make this area better than average? Even if this text is 100% accurate today, I'll bet a good lunch that it will be wrong in two or three releases.
Our attitude for questions at the level of detail that this is trying to cover has mostly been "someone who cares can go read the code". I grant that that's not a great answer, but it's largely stood the test of time.
I think it's reasonable to document the fact that we can do SQL function inlining in some cases, but not to try to specify which cases those are in exhaustive detail.
I agree so this can be fragile. But inlining has too high an impact on performance so I don't think a description somewhere on wiki is enough.
Now, the SQL functions can use plan cache too, so the overhead of execution of non-inlined SQL functions can be less, but still it is very important from performance perspective and often a source of performance issue. There can be notes, so described rules can be changed in the time, but I think the described behaviour is mostly very stable.
