Re: Changing SQL Inlining Behaviour (or...?)

On Mon, Dec 31, 2018 at 2:23 PM Adam Brightwell <
adam(dot)brightwell(at)crunchydata(dot)com> wrote:

>
> > * Solution #2 - Quick and dirty and invisible. Tom suggested a hack that
> achieves the aims of #1 but without adding syntax to CREATE FUNCTION: have
> the inlining logic look at the cost of the wrapper and the cost of
> parameters, and if the cost of the wrapper "greatly exceeded" the cost of
> the parameters, then inline. So the PostGIS project would just set the cost
> of our wrappers very high, and we'd get the behaviour we want, while other
> users who want to use wrappers to force caching of calculations would have
> zero coded wrapper functions. Pros: Solves the problem and easy to
> implement, I'm happy to contribute. Cons: it's so clearly a hack involving
> hidden (from users) magic.
> > ...
> > So my question to hackers is: which is less worse, #1 or #2, to
> implement and submit to commitfest, in case #3 does not materialize in time
> for PgSQL 12?
>
> I've been working with Paul to create and test a patch (attached) that
> addresses Solution #2. This patch essentially modifies the inlining
> logic to compare the cost of the function with the total cost of the
> parameters. The goal as stated above, is that for these kinds of
> functions, they would be assigned relatively high cost to trigger the
> inlining case.
>

I've tested this patch for both the internal types case and for the PostGIS
functions case, and in both cases it provides a way to get around the
undesirable inlining behaviour for our case without impacting people for
whom the behaviour has been desirable in the past.

Is this already in the commitfest?

P.

>
>