Re: Documenting inlining SQL functions

Hi

so 19. 7. 2025 v 5:08 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Sunday, July 6, 2025, Paul Jungwirth <pj(at)illuminatedcomputing(dot)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
>
>
>