> On Jan 19, 2019, at 5:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> I wrote:
>> Paul Ramsey <pram...@cleverelephant.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
