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

> On Jan 19, 2019, at 5:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I wrote:
>> Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
>>> Is there a rule of thumb we can use in costing our wrappers to ensure that they always inline?
>
>> Not really, which is a weak spot of this whole approach.
>
> BTW, it suddenly strikes me that at least for the specific cases you've
> shown in this thread, worrying about forcing inlining despite multiple
> parameter occurrences is solving the wrong problem. As I understand it,
> what you're doing is basically expanding some_operation(x,y) into
>
> x indexable_operator y AND exact_condition(x,y)
>
> where exact_condition(x,y) is semantically identical to
> some_operation(x,y), and the point of the maneuver is to inject
> an indexable operator that implements some lossy form of the
> exact_condition. But this is not an ideal solution: aside
> from the possible cost of evaluating x and y twice, adding
> the indexable_operator is just a dead loss if you don't end up
> with an indexscan on x.
>
> So ISTM what we *really* want is that the wrapper function is
> just an alias for exact_condition() --- which eliminates the
> multiple-evaluation hazards and hence the risk of not inlining ---
> and then teach the planner how to extract the indexable_operator
> when, and only when, it's actually useful for an indexscan.
>
> The machinery for that sort of thing already exists; it's what
> indxpath.c calls a "special index operator". But right now it's
> only applied to some built-in operators such as LIKE. I've had
> a personal TODO item for a very long time to make that ability
> accessible to extensions, but it never rose to the top of the
> queue. Maybe we should be trying to make that happen, instead
> of messing around with dubious changes to the inlining rules.
>
> Does this line of thought seem like it would fix your problem,
> or are there places where the inlining rules are causing you
> issues but the use-case doesn't look like "add a lossy indexable
> operator”?

While I’m not 100% sure what this new thing would “look like” there are at least a few quirky variations on the pattern you’ve correctly identified. So, ST_Intersects(a, b), ST_Contains(a, b) these all match the pattern.

One that is similar but not quite matching is ST_DWithin(a, b, radius), which expands to

a && expand(b, radius) and b && expand(a, radius) and _ST_DWithin(a, b, radius)

so the operator call is doubled up and includes a function all on one operand rather than a bare call.

there may be a few other non-standard pattern inlines lying around, but that’s the most commonly used one.

P

>
> regards, tom lane