Re: Changing SQL Inlining Behaviour (or...?) - Mailing list pgsql-hackers

On Jan 21, 2019, at 3:17 PM, Andres Freund <andres@anarazel.de> wrote:

Hi,

On 2019-01-19 20:53:55 -0500, Tom Lane wrote:

I wrote:

Paul Ramsey <pramsey@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"?

Paul, is what Tom calls indexable_operator here just useful for
indexability, or *also* useful to reduce the frequency of invoking the
exact_condition(), which presumably will frequently be much more
expensive to evaluate?  With the current scheme, as long as it works,
the indexable fastpath filters out rows quickly for both sequential and
index scans, but I'm not sure that'd work in the transformation scheme
Tom proposes.  Sure, the exact_condition could always do the cheaper
pre-check, but that'd be wasted effort in the index scan case, where
that'd presumably already be ruled out.

Actually an issue, or not?

Greetings,

Andres Freund