Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> But I wonder whether any better answer is possible. I don't want to
>> give up on the inlining optimization --- anyone see another fix?
> If a functional index applies to the function, generate one plan with the
> function inlined and one with the function call left in, and then plan
> away as usual. While that could blow up the number of plan choices to
> consider (which would have to be controlled in some way), this would give
> the best end results because the planner could consider the choice knowing
> what the function results are used for.
But there isn't any situation where the non-inlined version is "better",
so there isn't really a plannable choice to be made here. I'd be
willing to do the above if there were cases where it actually made sense
not to inline a simple function, and the planner could determine which
those were using cost estimates. But it seems like an inappropriate
workaround for not being able to match up functions with indexes...
The urge is becoming very strong to fix this by replacing functional
indexes with expressional indexes, as I suggested doing many moons ago.
Then the difficulty at hand would be easily handled by running the
index's defining expression through eval_const_expressions before
checking if it is equal() to a candidate WHERE argument. Not sure I
have time to do that before 7.4 though :-(
regards, tom lane
