From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Paul Jungwirth <pj(at)illuminatedcomputing(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Documenting inlining SQL functions |
Date: | 2025-07-18 19:57:12 |
Message-ID: | CAFj8pRCkBUb=nu2OTh7jxhcaCnD419H8m2xRw8_8VuPLae1kVg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
po 7. 7. 2025 v 5:12 odesílatel Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>
napsal:
> Hi Hackers,
>
> Here are some documentation patches about inlining SQL-language functions.
> Postgres has been able to
> inline both scalar and set-returning functions since the 9.x days (as long
> as they are LANGUAGE SQL
> and meet a bunch of other conditions). But this was never documented
> outside of a wiki page[1]. This
> is a very significant optimization, especially for SRFs with qual
> pushdown, but it is largely
> unknown. I recently checked five books on advanced Postgres usage, some
> specifically on query
> optimization, and none of them mentioned this feature. I think we should
> talk about it.
>
> Putting this in our docs also gives us a useful reference point for some
> support requests that do
> similar inlining, but with more user control. We already have a support
> request to let users inline
> single-result SQL functions[2], and I have a patch to do something similar
> for set-returning SQL
> functions[3]. I gave a talk at Postgres Extensions Day in Montreal that
> ties all this together,[4]
> and our docs could do something similar.
>
> The first patch just adds <sect2> elements to break up the Function
> Optimization section into two
> sub-sections: one covering declarative annotations and another covering
> support functions. No
> rewriting is needed.
>
> 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.
>
> I wonder if we should have some tests about this behavior also? I'm happy
> to add those, either as
> part of this commitfest entry or something separate.
>
> [1] https://wiki.postgresql.org/wiki/Inlining_of_SQL_functions
> [2]
>
> https://github.com/postgres/postgres/blob/bd3f59fdb71721921bb0aca7e16d483f72e95779/src/include/nodes/supportnodes.h#L64
> [3] https://commitfest.postgresql.org/patch/5083/
> [4] https://github.com/pjungwir/inlining-postgres-functions
>
>
I am checking this patch. The new content is very necessary.
I think the related page is well readable after patching.
This patch can be enhanced by some examples, and with a description how to
detect if a function was inlined or not.
Reards
Pavel
> Yours,
>
> --
> Paul ~{:-)
> pj(at)illuminatedcomputing(dot)com
>
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Herrera | 2025-07-18 20:09:33 | Re: Log prefix missing for subscriber log messages received from publisher |
Previous Message | Andres Freund | 2025-07-18 19:55:52 | Re: libpq: Process buffered SSL read bytes to support records >8kB on async API |