Hi so 19. 7. 2025 v 5:08 odesÃlatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> "David G. Johnston" <david.g.johns...@gmail.com> writes: > > On Sunday, July 6, 2025, Paul Jungwirth <p...@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. Regards Pavel > > regards, tom lane > > >
